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PREFACE 


This book is a supplement to SNA Format and Protocol Reference Manual: Architecture Logic 
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(S$C30-3112). It describes SNA network interconnection, also called gateway services. 


The body of the book gives an overview of gateway services, defining terms, showing examples of 
interconnected network configurations, describing SSCP session services in support of network 
interconnection, and showing the role played by the gateway function component within an SNA 
node. 


Appendix E gives request-response unit (RU) formats used for SNA network interconnection. This 
appendix contains a subset of the RUs shown in the SNA Reference Summary (GA27-3136), namely the 
RUs mentioned in this book. 

Appendix G includes sense data used for SNA network interconnection. 


Appendix N describes the notation used in the book. 


Abbreviations commonly used in the text are listed on foldout pages at the back of the book (Ap- 
pendix T) for easy reference. 


For an introduction to the design concepts of SNA network interconnection, see "Interconnecting 


SNA Networks," IBM Systems Journal, Vol. 22.5 No. 4.5 pp. 344-366, 1983 (which can be ordered 
through IBM branch offices using IBM Order No. 6321-5199). 
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CHAPTER 


1. SNA NETWORK INTERCONNECTION 


INTRODUCTION 


SNA network interconnection (SNI) allows independent networks to support cross-network end-user 
communication without giving up their autonomy. Each interconnected network has its own inde- 
pendent name space and address space, and is referred to as a subnetwork of a larger, 
multiple-address-space SNA network. 


This book describes the cooperation required among SNA components in order to achieve SNA net- 
work interconnection, also Known as gateway services. 


Multiple networks may be interconnected serially, or with parallel gateways between a given pair 
of networks, or with several networks interconnected through the same gateway. These configura- 
tions are described in this book. 


A major goal of SNI 1s to achieve network interconnection without any changes to components that 
are not specifically gateway capable. For example, from the point of view of an LU, the proce- 
dures for initiating, terminating, and using a session are the same whether the partner LU is in 
the same subnetwork or a different subnetwork. The following components are gateway capable, 
and are described in this book. 


e The gateway SSCP—an SSCP with the special data base and facilities required to participate 
in cross-netuork session initiation and termination. This book assumes some familiarity 
with the SSCP session services functions as described in SNA Format and Protocol Reference 
Manual: Architecture Logic. 


® The gateway function component—a component in a node on a subnetwork boundary that accepts 
message units from one subnetwork and transmits them to the appropriate destination in 
another subnetwork. 


e The gateway PU-—the PU in the same node as a gateway function component; the gateway PU 
receives RUs from a gateway SSCP concerning cross-network sessions. 


The gateway function component and the gateway PU are referred to collectively as the gate- 
way node. 


Another goal of SNI is to allow interconnected networks to be configured, defined, and managed 
independently. Gateway nodes and gateway SSCPs allow different networks to mask their physical 
and logical configurations from each other, primarily by offering the following services, which 
are described in this book: 


e Address aliasing, allowing duplicate addresses and different subarea/element splits in the 
interconnected networks 


¢ Name aliasing, allowing duplicate network names in interconnected networks 


e Routing of session services RUs between SSCPs in different subnetworks of the composite net- 
work, minimizing the data about one subnetwork that is Kept by SSCPs in other subnetworks. 
Thus, a configuration change in one subnetwork does not require changes in the routing 
tables or directory entries of all SSCPs in the interconnected subnetworks. 


TERMS AND CONCEPTS 


CROSS-NETWORK SESSION 


A cross-network session crosses one or more subnetwork boundaries. It connects two LUs in dif- 
ferent subnetworks or a gateway SSCP in one subnetwork to an SSCP tn another subnetwork, where 
the second SSCP may or may not be a gateway SSCP. 
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DEFINITION OF GATEWAY 


A gateway consists of the SNA components that participate in name transformation, network 
address transformation, and SSCP rerouting in order to allow the interconnection of two or more 
networks with independent name and address spaces. A gateway includes one gateway node and at 
least one gateway SSCP. 


Several gateway SSCPs may support a single gateway node, i.e., send the gateway node PU RNAA and 
SETCV requests related to cross-network sessions. The maximum number of gateway SSCPs that may 
support a particular gateway node is less than or equal to the share limit for the gateway PU, 
since non-gateway SSCPs may also share control of a gateway PU. 


For a single LU-LU session, a maximum of three gateway SSCPs per gateway can partition responsi- 
bility for name transformation and gateway node support. See "Gateway SSCP Functions" on page 
1-30 for the rules governing the allocation of responsibilities among gateway SSCPs. 


Although physically located in a single subnetwork, a gateway SSCP may participate in gateways 
Spanning boundaries between different sets of subnetworks. The architecture does not determine 
the exact number and physical locations of gateway SSCPs involved in a gateway supporting an 
LU-LU session. However, different gateway configurations may affect the number of cross-network 
SSCP-SSCP sessions required and the information required in the tables of the different gateway 
SSCPs. "Configurations" on page 1-3 discusses some of these considerations. 


NETWORK IDENTIFIERS 


A network identifier uniquely identifies a subnetwork within a set of two or more interconnected 
subnetworks. A network identifier serves two purposes: 


e The network identifier identifies the address space associated with an address in RUs 
exchanged by gateway components. 


® The network identifier identifies the name space associated with an SSCP name, LU name, 
class of service (COS) name, or mode name. 


A network-ID-qualified name or address is always unique in the entire set of interconnected sub- 
networks. 


VIRTUAL ROUTES 


A cross-network session has a virtual route in each subnetwork through which its session traffic 
travels. These routes are disjoint. A gateway function component transfers session traffic 
between the two virtual routes terminating in its node, as described in "Gateway Function Compo- 
nent'' on page 1-13. 


LU ROLES IN SESSION INITIATION 


The LUs that participate in session initiation are classified according to the following roles 
that they play. See SNA Format and Protocol Reference Manual: Architecture Logic for more 
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information about these roles. 

¢ The initiating LU (ILU) is the one that sends the INIT-SELF or INIT-OTHER RU. 

e The terminating LU (TLU) is the one that sends the TERM-SELF or TERM-OTHER RU. 

® The primary LU (PLU) is the one that sends the BIND RU. 

e The secondary LU (SLU) 1s the one that receives the BIND RU. 

e The origin LU (OLU) is the LU whose SSCP originates a CDINIT RU or CDTERM RU. It is either 
the primary or the secondary LU. For session initiation, this LU 1s either the ILU (if it 
sent INIT-SELF) or the LU named second in the INIT-OTHER (in which case, it may or may not 
be the ILU). Similarly, for session termination, this LU is either the TLU (if it sent 


TERM-SELF) or the LU named second in the TERM-OTHER Cin which case, it may or may not be the 
TLU). 


® The destination LU (DLU) 1s the one named in the TERM-SELF RU or named first in the 
TERM-OTHER RU. It is either the primary LU or the secondary LU. 
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CONFIGURATIONS 


This section shows different configurations of interconnected subnetworks, first in terms of 
gateways, and then in terms of the gateway components comprising the gateways. 


NETWORK CONFIGURATIONS 


Multiple subnetworks can be interconnected both serially and in parallel. This section shows 
some of the basic configurations that can be combined to create a wide variety of 
multtple-network configurations. Different configurations have different performance, reliabil- 
ity, and cost characteristics. 


In the simplest case, two subnetworks are interconnected using a single gateway, as shown in 
Figure 1-1. 
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Figure 1-1. One Gateway Connecting Two Networks 


Two subnetworks can also be interconnected using multiple, parallel gateways, as shown in Fig- 
ure 1-2. 


AAAAAAAAAA BBBBBBBBBB 
GATEWAY B 
B 


NETWORK A NETWORK B 


A 
AAAAAA : BBBBBBBBBB 


Figure 1-2. Parallel Gateways Connecting Two Networks 
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Three or more subnetworks can also be interconnected using. one or more gateways. 


Figure 1-3 


shows three subnetworks interconnected using a single gateway. 
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Figure 1-3. One Gateway Connecting Three Networks 


Multiple subnetworks can be interconnected by tandem gateways, as shown in Figure 1-4. 
networks may access one another via one or more intermediate subnetworks. 
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Figure 1-4. 


1-4 


Ccccc 


GATEWAY | NETWORK 
: Cc 


Tandem Gateways Connecting Three Networks 


Systems Network Architecture Format and Protocol Reference Manual: SNA Network Interconnection 


CONFIGURATIONS OF GATEWAY COMPONENTS 


The figures in this section show the gateway components that participate in the gateway config- 


urattons shown above. They also show the sessions involved in the initiation of a single 
cross-network LU-LU session. 


Figure 1-5 shows the minimum set of gateway components involved in the simple one-gateway con- 
figuration illustrated in Figure 1-1 on page 1-3. 


This configuration requires only one of the subnetworks to contain a gateway SSCP. Every SSCP 
in subnetwork B that participates in cross-network session initiation must have a session with 
the gateway SSCP in subnetwork A. From the point of view of the SSCPs in subnetwork B, all LUs 


in subnetwork A appear to be in the domain of the gateway SSCP; they also appear to be in the 
subarea of the gateway node. 
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Figure 1-5. One Gateway Connecting Two Networks: One Gateway SSCP 
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Figure 1-6 shows a slightly more complex example of the simple one-gateway configuration, with a 


second gateway SSCP added 


cross-network forwarding of RUs by SSCPs: 


in the second subnetwork. 


It offers the benefits of simplified 


only one SSCP-SSCP cross-network session is required. 


In addition, name aliasing functions (see "Name Aliasing and Transformation" on page 1-19) may 
be coordinated so that the required tables can be partitioned between the two gateway SSCPs. 
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Figure 1-6. 
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One Gateway Connecting Two Networks: 
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Two Gateway SSCPs 


SNA Network Interconnection 


Figure 1-7 shows an example of the parallel-gateway configuration shown in Figure 1-2 on page 
1-3, in which the same gateway SSCP belongs to both gateways. The cross-network LU-LU session 
1S not constrained to pass through the same gateway node as the cross-network SSCP-SSCP session 
involved in its initiation. In the figure, the cross-network SSCP-SSCP session crosses the sub- 


network boundary through gateway 1, while the LU-LU session crosses it through gateway 2. 


Providing parallel gateways increases the number of cross-network sessions that may be estab- 
lished and provides a backup path for cross-network sessions if one of the gateway nodes becomes 


inoperative. 


Network A eee es et Ben aS) ce Eh eh a xe Network B 


Gateway Nodel 


a ° 
Gateway wenn | 6 SSCP 
PUL g (SLU) 
& ° 
a e 
cs Re % : ‘ > Gateway : 


Function 
a 


Gateway 1 


HUH HH HM HH ¥ uw . 
» * Gateway 2 % i < 
% * e : 
. * * w " 
= & Gateway * 7 é 
¥ SSCP * " a 
. * x " . 
a ee e% Me ge a we ees we ee 
¥ % = 
x HMM KH HH MMH HHH HM 
% w % 
HMM HIM KH H * x " % 
u * 
SSCP w * 
(PLU) Gateway Node2 % 
a * 
| Gateway # 
PU2 * 
5 * 
n % 
PLU Gateway SLU 
% Function % 
* s 3% 
* ¥ 
HH KR HH HOH KH HH HK 
Sessions 
Gateway ———————————— :dSSCPISLU) 
SSCP | 
| Gateway PU2 
SSCP 


PLU -—————_—————————:s OSLU 


Note: Gateway PUL is not shown in the session diagram because it does not 
participate in the setup of the LU-LU session. 


Figure 1-7. Parallel Gateways Connecting Two Networks: One Gateway SSCP 
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Figure 1-8 shows a set of gateway components constituting the configuration illustrated in Fig- 
ure 1-3 on page 1-4. Only one subnetwork is required to have a gateway SSCP. In this example, 
all three subnetworks have their own gateway SSCPs, which share gateway node support responsi- 
bilities for a given session. 


Typically, no more than two gateway SSCPs in a given gateway are involved in any given session. 
However, a third gateway SSCP is allowed to serve as an intermediary between two entirely inde- 
pendent networks. For example, one network may provide several different networks with access 
to services provided by each other. Each network contracts with the single network, which con- 
trols the establishment of cross-network sessions between any pair of networks. 


Three is the maximum number of gateway SSCPs per gateway that may be involved in the initiation 
of a particular session. 
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Figure 1-8. One Gateway Connecting Three Networks: Three Gateway SSCPs 
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A gateway SSCP may be involved in tandem gateways connecting three subnetworks. Figure 1-9 and 


Figure 1-10 on page 1-10 show two examples of the tandem gateway configuration shown in Fig- 
ure 1-4 on page 1-4. 


In Figure 1-9, the only gateway SSCP is in the intermediate subnetwork. This gateway SSCP is 
involved in two gateways that connect different subnetworks; - it supports both gateway nodes 
involved in the session. 
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Figure 1-9. Tandem Gateways Connecting Three Networks: One Gateway SSCP 
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In Figure 1-10, the intermediate subnetwork B has no LUs or gateway SSCPs; it consists entirely 
of links between the two gateway nodes. This configuration provides the maximum isolation 
between subnetworks A and C, since neither gateway SSCP has a session with the gateway node on 
the subnetwork boundary of the other. 


In an active gateway, the gateway PU has an active session with at least one gateway SSCP in one 
of the subnetworks connected in the gateway. Hence, this figure illustrates the greatest sepa- 
ration possible between two gateway SSCPs that share a session: two gateway nodes between them. 
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Figure 1-10. Tandem Gateways Connecting Three Networks: Two Gateway SSCPs 


GATEWAY-CAPABLE COMPONENTS 
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GATEWAY SSCP 


A gateway SSCP is an SSCP that is able to support gateway PUs, to reroute session services RUs 
between SSCPs in separate subnetworks, and to make the appropriate name and address transf- 
ormations within these requests, as described in “Address Aliasing and Transformation" on page 
1-16 and "Name Aliasitng and Transformation" on page 1-19. 


An SSCP that is able to be a gateway SSCP may or may not participate in a gateway for a partic~ 
ular LU-LU session. If so, it reroutes session services RUs across subnetwork boundaries and 
participates in the control of gateway nodes involved in the session. If not, it behaves as if 
it were a non-gateway SSCP, sending session services RUs to another gateway SSCP in its subnet- 
work for rerouting. 
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A gateway SSCP belonging to multiple parallel gateways may select the gateway node to be used by 
a particular LU-LU session to cross a subnetwork boundary, since the LU-LU session is not con- 
strained to use the same gateway node as the SSCP-SSCP session. 


To a non-gateway SSCP, all LUs in other networks appear to be in the domain of an SSCP session 
partner (a gateway SSCP), which appears to be in the same subnetwork, whether or not the con- 
necting session 1s a cross-network session. 


Summary of Cross-Network Session Services 


Session initiation and termination for an LU-LU session are mediated by one or more SSCPs. If 
the two LUs are in the same domain, only one SSCP is involved. If the two LUs are in different 
domains, two SSCPs are involved, exchanging cross-domain session. services RUs. For 
cross-network LU-LU sessions, two or more SSCPs are involved, including at least one gateway 
SSCP. If multiple SSCPs are involved, they appear to an LU as a single, composite SSCP. For 
example, a composite SSCP includes the SSCP of the OLU, the SSCP of the DLU, and all the gateway 
SSCPs that route session services RUs between them (see "SSCP Rerouting" on page 1-23). 


Figure 1-11 illustrates this principle. If the OLU and the DLU belong to the same domain, steps 
2, 4, 8) and 9 are unnecessary. This figure is a simplification of the flows shown tn Fig- 


ure 1-32 on page 1-37 and Figure 1-34 on page 1-39, deleting responses and showing only flows 
between SSCPS and other SSCPs or LUs. 
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Figure 1-11. Cross-Network LU-LU Session Activation with Multiple SSCPs: <A response is not shown if 
it immediately follows the corresponding request. 


Predesignated Gateway SSCP 


It is an installation option to predesignate one gateway SSCP to have sole responsibility for 
control of the gateway node. The functions of the predesignated gateway SSCP are described in 
"Gateway SSCP Functions" on page 1-30. 


For example, gateway SSCP2 1n subnetwork B in Figure 1-8 on page 1-8 may be predesignated 
because the installation requires it to have sole control of the gateway node. 


An SSCP notifies its session partner gateway SSCPs in the CDINIT request or response that it 15s 
predesignated to control a common gateway node. 


Only one gateway SSCP Ina gateway may be predesignated. If three gateway SSCPs serve a single 


session, only the middle one in the session setup path (see "SSCP Rerouting'' on page 1-23) may 
be predesignated. : 
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GATEWAY NODE 


A gateway node interconnects two or more subnetworks. It has the following characteristics: 


e It contains two or more subarea path controls, each associated with a particular subnetwork. 
Each subarea path control can perform normal intermediate routing within its subnetwork. 


e It contains a gatenay function component that interconnects pairs of subarea path controls 
for cross-network sessions. 


° The gateway PU has a network address in each interconnected subnetwork. 


¢ The gateway PU can process gateway RNAA and SETCV RUs from a gateway SSCP. 
Native Network 


Although the PU in a gateway node may have SSCP-PU sessions with SSCPs in more than one subnet- 
work, only the SSCPs in one subnetwork can control the subsidiary resources of the PU, such as 
links and LUs. This subnetwork is called the native network of the gateway node. For example, 
only the SSCPs in the native network can have SSCP-LU sessions with the LUs in the gateway node 
or with the LUs in peripheral nodes attached to the gateway node. 


Gateway PU 


A gateway PU is distinguished by its ability to handle the gateway-related information in the 
RUs shown in Figure 1-12 on page 1-13. The figure shows the complete set of RUs required to 
establish the SSCP-PU session and to conduct gateway-related activities. These are the only RUs 
that may be exchanged by a gateway PU and a gateway SSCP that is not in tts native network. 


The following notes explain the gateway-related information carried in, or implied by each RU in 
the figure, where the notes correspond to the numbers in the figure. See Appendix E for the 
complete format of each RU. 


1. The SSCP-PU Session Capability control vector (X'0B') on ACTPU informs the gateway PU of the 
gateway capability of the SSCP. In RSP(ACTPU), the PU indicates in control vector X'0OB' 
whether it has the same gateway capabilities. 


2. Pending-active or pending-reset cross-network LU-LU sessions that are being activated in 
cooperation with the sender of DACTPU will be reset by the gateway node. 


3. To support cross-network route status reporting and testing, the gateway PU sends ROUTE-INOP 
and ER-TESTED and receives ROUTE-TEST for routes in any subnetwork connected by the gateway 
node. These three RUs include the network identifier for the referenced route. The gateway 
PU reports all inoperative routes (via ROUTE-INOPs) to the SSCPs that have requested such 
reporting tn ACTPU control vector X'0B', whether or not they are gateway SSCPs. 


4. <A gateway SSCP and a gateway PU exchange RNAA and SETCV to set up the address transform for 
a cross-network session, as described in "Address Assignment Protocols" on page 1-17. A 
gateway SSCP also uses SETCV to send the gateway PU the LU name transform, as well as VR 
identifier lists used to request virtual routes in specified subnetworks. 


5. A gateway SSCP sends NOTIFY(X'05') to inform the gateway PU that a session setup error con- 
dition has been detected, e.g., because the DLU is not available. As a result, the gateway 
node can free the resources allocated during the RNAA-SETCV sequence. 


6. The gateway PU sends NOTIFY(X'05') to each gateway SSCP that has participated in the setup 
procedures for a session when it detects session activation or deactivation or has detected 
a session failure resulting from an inoperative route. 


7. The gateway PU sends REQACTCDRM to a gateway SSCP after it receives an ACTCDRM request for 
which 1t has no established address transform. REQACTCDRM signals the gateway SSCP to tni- 
tiate the cross-network SSCP-SSCP session with the sender of the unsuccessful ACTCDRM. For 
more information, see Figure 1-30 on page 1-35 and Figure 1-31 on page 1-36. 


Two other RUs processed by PUs have been modified for SNA network interconnection: CONTACTED 


includes a network identifier for the contacted station. In NC_ER_TEST_REPLY, the ER Configura- 
tion control vector (X'1F') includes a network identifier. 
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Figure 1-12. RUs Flowing between Gateway PUs and Gateway SSCPs 


Gateway Function Component 


Figure 1-13 on page 1-14 shows similarities between gateway function components and boundary 
function components (not otherwise described in detail in this book). Both include session con- 
nectors (SC) that interconnect pairs of path controls. A session connector transfers message 
units from one path control to another, allowing two NAUs to communicate even though they are 
represented in separate address spaces. As far as the two NAUs are concerned, a session con- 
nected through boundary function or gateway function is like any other session; the NAUs are 
not aware of the session connector interconnecting them. 


As far as the two path controls are concerned, the session connector appears to be a 
half-session. The two path controls are associated with different address spaces, and thus know 
the session connector by different address pairs. 


Thus, a boundary function session connector transfers message units between a subarea path con- 
trol and a peripheral path control. The session connector has an address tn a subarea address 
Space and one 1n a peripheral address space. Boundary function allows SSCPs and LUs in a sub- 
area routing network to communicate with LUs and PUs in peripheral nodes. 


Similarly, a gateway function session connector transfers message units between independent sub- 
area path controls. The session connector has two different subarea address pairs belonging to 
the two different subarea address spaces associated with the two subarea path controls. Gateway 
function allows SSCPs and LUs in one subnetwork to communicate with SSCPs and LUs in another 
subnetwork. 
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Figure 1-13 on page 1-14 also shows the session types supported by both boundary function and 
gateway function. Through boundary function, an SSCP can communicate with both LUs and PUs, 
while an LU can communicate with other LUs. Through gateway function, an SSCP can communicate 
only with other SSCPs, and an LU can communicate only with other LUs. Cross-network SSCP-LU or 
SSCP-PU sessions do not exist. | 
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Figure 1-13. Gateway Function Compared to Boundary Function: One session connector (SC) exists for 
each session connected through a boundary function or gateway function. 
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In Figure 1-14, network A is the native network of the gateway node. All the peripheral nodes 
attached to it belong in this network. 


Session traffic flowing from an LU in the peripheral node to an LU in network B follows the path 
described below through the gateway node: 


® The peripheral path control delivers it to boundary function. 
® Boundary function delivers 1t to the subarea path control for network A. 
® This subarea path control delivers it to gateway function. 


® Gateway function delivers it to the subarea path control for network B, which forwards it to 
the destination LU. | 


Session traffic flowing in the opposite direction takes the reverse path. 
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Figure 1-14. Flow between Gateway Function and Boundary Function 
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Structure of a Gateway Function Component 


As shown in more detail in Figure 1-15, a gateway function component consists of one session 
connector for each cross-network session whose session traffic passes through that gateway node 
and a session manager. 


The session manager manages cross-network session-activation and -deactivation protocols for the 
gateway node. It receives session-activation and -deactivation requests and responses from one 
subarea path control and retransmits them via another subarea path control; it also creates and 
destroys the associated session connectors. The session manager 1s comparable to the network 
services component (LNS) in the LU. 


Each session connector interconnects two subarea path controls for a particular cross-network 
session. It receives session traffic from one subarea path control and retransmits it via the 
other. To the subarea path controls, the session connector appears to be a half-session. Each 
subarea path control associates the session connector with an address pair in its address space. 
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Figure 1-15. Structure of a Gateway Function Component 


ADDRESS ALIASING AND TRANSFORMATION 
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To establish uniqueness of an address among interconnected subnetworks, the address is qualified 
by the network identifier. In the RUs they exchange, gateway SSCPs and gateway PUs use 
network-ID-qualified addresses to be unambiguous. However, path control and other NAUs within a 
subnetwork are not aware of other subnetworks and do not use network-ID-qualified addresses. 
The purpose of address aliasing is to avoid address ambiguities without requiring the general 
use of network-ID-qualified addresses. 


Address aliasing provides an alias network address within one subnetwork address space to repre- 
sent a NAU residing within another subnetwork. The alias address and its counterpart in the 
other address space may have different subarea/element splits. 


ADDRESS ASSIGNMENT ALGORITHM 


Alias addresses used for either SSCP-SSCP or LU-LU sessions may be either system-defined or 
dynamically assigned during session initiation. If an alias address 1s system-defined, it is 
always used for sessions with a particular NAU in another network. 


Each gateway node has a pool of addresses from which it can assign alias addresses. Except for 
the constraints defined in SNA Format and Protocol Reference Manual: Architecture Logic, the 
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address assignment algorithm 1s implementation defined. 
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ADDRESS ASSIGNMENT PROTOCOLS 


The primary purpose of the address assignment protocols is to provide each gateway node along a 
session path with two address pairs for the cross-network session. As session traffic flows 
through the gateway node, the gateway node transforms the address fields in the transmission 
header (TH) from values meaningful in one subnetwork to values meaningful in the other. 


For a cross-network session, an SSCP or LU in one subnetwork is represented by an alias address 
in each other subnetwork through which the session traffic flows. Thus, a minimum of two alias 
addresses are assigned for each session. As shown in Figure 1-16, the address pair in each sub- 
network contains the alias address of the SSCP or LU in the other subnetwork and the real 
address of the local SSCP or LU (1i.e., the one used for routing within its own subnetwork). If 
the subnetwork is an intermediate network, such as network B in Figure 1-10 on page 1-10, both 
addresses associated with the session are alias addresses. 
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Figure 1-16. Address Transformation: Gateway node 1 transforms TH address pair 1 to TH address pair 
2, and vice versa. Gateway node 2 does the same for TH address pair 2 and TH address 
pair 3. 


During session initiation, a gateway SSCP sends an RNAA request to the gateway PU to cause both 
alias addresses to be assigned. The RNAA carries the real address of the origin LU or SSCP, 
along with the network-ID-qualified real names of both session partners. The gateway node 
assigns two alias addresses to the session, and returns them in the RNAA response. It may use 
the NAU names during the assignment, e.g., to determine whether it has a system-defined address 
associated with a DLU. The gateway node acquires the real address of the destination LU or SSCP 
from a SETCV RU sent by a gateway SSCP later in the session initiation sequence, as shown in 
Figure 1-29 on page 1-34 and Figure 1-32 on page 1-37. For SSCP-SSCP sessions, this address is 
system-defined in the gateway SSCP. For LU-LU sessions, the address is acquired from the SSCP 
of the DLU by further exchange of session services RUs. These protocols are illustrated in Fig- 
ure 1-17 on page 1-18. 
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RSP(RNAA, OLU Alias Address, DLU Alias Address) X X 


Real Alias 


SETCV(DLU Real Address) X x 


Figure 1-17. Gateway Node Acquisition of an Address Transform 


For intermediate subnetworks, addresses may be aliases, even though they appear to be real 
addresses to particular gateway nodes. For example, in Figure 1-16 on page 1-17, X_ALIAS_IN_B 
appears to gateway node 2 as the real address of X, even though it is an alias address assigned 
by gateway node 1. 


SYSTEM-DEFINITION CONSIDERATIONS 


Each SSCP has a system-defined address for each SSCP with which it can have a session. Thus 
each gateway SSCP has a network-ID-qualified address for each SSCP with which it can have a 
cross-network session, and each non-gateway SSCP has an alias address for each gateway SSCP with 
which it can have a cross-network session. 


ADDRESS TRANSFORM RELEASE 


An address transform is released by a gateway PU when the session associated with it terminates, 
or when a gateway SSCP sends a NOTIFY(X'05') instructing the gateway PU to release the session 
resources. 


A dynamically assigned alias address is released when the last address transform using it is 
released. 


ADDRESS TRANSFORMATION PERFORMED BY A GATEWAY SSCP 


Before sending a session services RU to another SSCP, a gateway SSCP transforms the addresses 
appearing in the RU if necessary, so that they are network-ID-qualified addresses, if the part- 
ner SSCP is a gateway SSCP, or real or alias addresses meaningful in the destination subnetwork, 
if the partner SSCP is not a gateway SSCP. 


ADDRESS TRANSFORMATION PERFORMED BY A GATEWAY NODE 


The gateway node transforms the addresses in the transmission header of each message unit cross- 
ing a subnetwork boundary according to the address transform previously established by the 
exchange of RNAA and SETCV RUs. 
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NAME ALTASING AND TRANSFORMATION 


Each subnetwork has an independent name space, which includes names for the following objects: 

® Real names for SSCPs in the local subnetwork 

® Real names for LUs in the local subnetwork 

e Alias names for LUs in other subnetworks 

e Class-of-service (COS) names 

° Mode names 

The transformation of alias LU names at subnetwork boundaries prevents name ambiguities, while 
still allowing each subnetwork to have an independent name space. LU names appearing in RUs are 
transformed between real names and alias names as required, so that the names belong to the name 
Space recognized by the receiver of the RU. Name aliasing allows subnetworks to be intercon- 
nected without concern for duplicate use of LU names. 

Each alias name is installation assigned. To avoid name conflicts, it should not be the same as 
any other name in its name space. Since name spaces are independent, there is no coordination 


of name assignment between connected subnetworks. 


Mode names and class of service (COS) names are also transformed by gateway SSCPs as RUs cross 
subnetwork boundaries. 


Figure 1-18 shows the data used by a gateway SSCP to transform names. Name transformations are 
discussed further below. 


Netid—A.alias—LU—name Netid-B.real—-LU—name (See Note 2.) 
Netid-A.real—LU—name and Netid-B Netid—-B.alias—LU—-name 
Netid-A.mode—-name and Netid—B Netid-B.mode—name 


Netid-A.COS—name and Netid-B Netid—-B.COS—name 


Figure 1-18. Data Used for Name Transformation: 


Notes: 


1. Netid-x.name represents a network-ID-qualified name. This figure shows the 
information required for the transformation; the information may not appear’ in 
exactly this form in the RUs that trigger the transformation. 


The transformation from alias to real LU name may optionally yield the name of the 
SSCP of the LU, which can then be used for SSCP rerouting (see Figure 1-24 on page 
1-26). 


SSCP names that appear in RUs crossing subnetwork boundaries are always network-ID-qualified. 
As a result, no problem is associated with using duplicate SSCP names in different subnetworks. 


Name aliases, if required, are predefined within gateway SSCPs. If an alias name is not pro- 
vided, it is assumed to be the same as the real name. 


LU NAME TRANSFORMATION 


LU names appearing in RUs on SSCP-SSCP flows are transformed by gateway SSCPs into their 
counterparts in the destination subnetwork. 
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1-20 


If a gateway SSCP is the only gateway SSCP between the SSCP of the origin LU and the SSCP of the 
destination LU (see "SSCP Rerouting" on page 1-23), it transforms an alias LU name to a real LU 
name and a real LU name to an alias LU name. 


Otherwise, one of the gateway SSCPs in the first gateway transforms any alias LU names in the RU 
to network-ID-qualified real names. Any gateway SSCP along the path may transform the real 
names to alias names recognized in the destination subnetwork. Information used for LU name 
transformation is shown in lines 1 and 2 of Figure 1-18 on page 1-19. 


If the first gateway has more than one gateway SSCP, network-ID-qualifited names are not required 
until aeo§gateway SSCP sends RNAA to the gateway node. This allows knowledge of 
network-ID-qualified names to be limited to one gateway SSCP in a gateway. 


At least one gateway along a tandem gateway path is able to map from real to alias names on 
behalf of the destination subnetwork. For example, the OLU real name in CDINIT is transformed 
to an alias name at or before the destination subnetwork's gateway. 


Intermediate subnetworks through which session services RUs may flow do not need alias LU names. 
All session services RUs flowing through intermediate subnetworks are transmitted between gate- 
way SSCPs and use network-ID-qualified LU names. Thus, LU name aliasing is done for the origin 
subnetwork and the destination subnetwork and for none between. 


Figure 1-19 on page 1-21 shows a CDINIT LU-name aliasing example with three networks in tandem. 
LUa in network A is initiating a session with LUc in network C. However, the name LUc is 
already used in network A. Consequently, LUc in network C is Known in network A as LUx. SSCPa 
defines LUx to be in the domain of gateway SSCP1. 


Gateway SSCP1 in the first gateway recognizes LUa to be the real name of the OLU in network A. 
Gateway SSCP1 determines that LUx is not in its own domain and transforms the alias name LUx to 
the network-ID-qualified real name C.LUc before sending the RU to gateway SSCP2. The real name 
of C.LUc belongs to network C's name space and 5s» does not need further transformation. The 
name A.LUa requires transformation to a name meaningful in network C's name space. The CDINIT 
RU format allows this transformation to be done at any gateway SSCP along the session setup path 
(including gateway SSCP1 in this example). Gateway SSCP2 (the last gateway SSCP) checks that 
the transformation has been done. In this example, the name A.LUa is transformed to LUz by 
gateway SSCP2. 


The above example illustrates that Knowledge of an alias-to-real transform can be confined to a 
gateway immediately adjacent to the subnetwork in which the alias is required. Thus, gateway 
SSCP1 does not Know the alias name used in network C for LUa. | 


The example also shows that subnetwork B (the intermediate subnetwork) does not need an alias 
name for either A.LUa or C.LUc. | 
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NETWORK A 


LUa Gateway 
SSCPa SSCP1 


NETWORK 6B NETWORK C 


Gateway 
SSCP2 


———_-_—_—— > 
CDINIT OLU=LUa | 
DLU=LUx > 
CDINIT OLU=A.LUa | 
DLU=C.LUc > 
CDINIT OLU=LUz 
DLU=LUc 


Figure 1-19. LU Name Transformation on a Three-Network CDINIT Flow: LUx and LUz are alias names, to 
avoid confusion between the names of local LUs and other-network LUs. In the 
intermediate network, network-ID-qualified names are used to avoid confusion with the 
names of local 'LUs. The real name, A.LUa, is transformed to an alias, LUz, before the 
CDINIT is delivered. 


Names in BIND RUs are transformed by the gateway node. <A gateway SSCP sends a SETCV request to 
inform the gateway node of the name transform to be used. 


MODE NAME TRANSFORMATION 


A mode name represents a set of session parameters requested by an LU. Since different subnet- 
works need not use the same mode name for the. same set of session parameters, gateway SSCPs 
transform the mode name specified in the source subnetwork to the one used for the same set of 
parameters in the destination subnetwork. 


Any gateway SSCP in the session setup path (see "SSCP Rerouting" on page 1-23 ) that has the 
required information may transform the mode name. This information is shown in line 3 of Fig- 
ure 1-18 on page 1-19. 


The mode name is transformed from the one used in the source subnetwork only to the one used in 
the destination subnetwork; since intermediate subnetworks do not use the mode name, it is not 
transformed into a mode name in their name spaces. 


CLASS OF SERVICE (COS) NAME TRANSFORMATION 


A class of service (COS) name represents characteristics of the virtual route connecting two 
NAUs. Since different subnetworks may use different COS names to represent the same route char- 
acteristics and since the session requires a route in each subnetwork, a COS name is required in 
the name space of each subnetwork traversed by the LU-LU session. Data used for COS name trans- 
formation is shown in line 4 of Figure 1-18 on page 1-19. 


A COS name appears may or may not appear in a CDINIT request. If a COS name does appear, it is 
transformed to a COS name meaningful in the subnetwork of the DLU by the gateway SSCP that 
transformed the DLU name. 

A CDINIT response contains one or two COS names: 

® Between two gateway SSCPs in different gateways,» a single COS name is included. This COS 


name belongs to the name space of the subnetwork on the OLU side of the sender's gateway and 
the DLU side of the receiver's gateway. 
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e Between two gateway SSCPs in the same gateway, two COS names may be included. One is the 
COS name in the subnetwork on the DLU side of the gateway and the other is the COS name in 
the subnetwork on the OLU side. The OLU-side COS name may be provided by any gateway SSCP 
in the gateway, but it is not required to be known until the the last gateway SSCP in the 
gateway. 


These rules are illustrated in Figure 1-20. The middle gateway SSCP in the first gateway trans- 


forms the COS name to one meaningful in network C. No COS name is required for network B, since 
the LU-LU session will not pass through that network. 


Network A Network B Network C 


. Gateway 5% Gateway e 
Se og ree caer ahi | 


. a 
a & 
SSCP i... Gateway! ® Gateway Gateway Gateway 
a 


+RSP(CDINIT, DLU-side COS name: COS_IN_A,> 


OLU-side COS name not present [not Known yet]) 
eee | 
+RSP(CDINIT, DLU-side COS name: COS_IN_A, 
OLU-side COS name: COS_IN_C) 
oe 
+RSP(CDINIT, DLU-side COS name: COS_IN C, 


OLU-side COS name not present) 
eT) , e & 


Figure 1-20. Class of Service Names in RSP(CDINIT): DLU-side and OLU-side are defined with respect 
to the SSCP that receives the RU. 


Before it forwards a BIND request, each gateway node uses a list of virtual routes for the sub- 
network on the SLU side in order to have a virtual route assigned to the session. A gateway 
SSCP in the gateway resolves the COS name in the subnetwork on the SLU side to a VR identifier 
list, and sends the list to the gateway node in control vector X'1B' on a SETCV request. Since 
either the OLU-side COS name or the DLU-side COS name can be the SLU-side COS name, the gateway 
SSCP requires both. 


Figure 1-21 on page 1-23 summarizes the transformation done for names and addresses. Alias 
addresses are required in intermediate subnetworks, while alias LU names are not. 
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NETWORK A NETWORK. B NETWORK C 


Addresses: Addresses: Addresses: 


Y_ALIAS_IN_A Y_ALIAS IN B Y_REAL 
X_REAL Gateway X_ALIAS_IN_B Gateway X_ALIAS_IN_C 
1 2 
LU Names: LU Names: LU Names: 
Y_NETIDQ_REAL 
X_NETIDQ_REAL 


Y_ALIAS_IN_A 
X_REAL 


Y_REAL 
X_ALIAS_IN C 


‘Mode Name: Mode Name: Mode Name: 


MODE_IN_A Either 
MODE_IN_A or 
MODE_IN_C 


MODE_IN_C 


COS Name: COS Name: COS Name: 


COS_IN_A COS_IN_B COS_IN_C 


Figure 1-21. Aliasing and Transformation Summary: NETIDQ stands for network-ID-quali fied. 


SSCP REROUTING AND GATEWAY NODE SELECTION 


SSCP REROUTING 


As shown in the figures in "Configurations" on page 1-3, the SSCPs involved in session services 
for a cross-network LU-LU session may be separated by one or more gateway SSCPs. In order for 
the two SSCPs with primary responsibility for session services for the session (e.g.» the SSCPs 
of the OLU and DLU) to exchange RUs, a path is established between them that may have more than 
one leg. Each leg of the path is an SSCP-SSCP session, where at least one of the session part- 
ners 1s a gateway SSCP. The process of forwarding RUs along the path by the intermediate gate- 
way SSCPs 1s called SSCP rerouting, and the path is called the session setup path. In complex 
configurations, such as tandem gateways, the rerouting may involve a path with several gateway 
SSCPs in the middle. 


A session setup path is established for the life of an LU-LU session during the flow of a CDINIT 
request. As part of their CDINIT processing, the gateway SSCPs remember the successful path so 
that they can use it for all subsequent session services RUs concerning that session. As 
described in "LU-LU Session Awareness Maintained by Gateway Components" on page 1-28 , the path 
is destroyed when awareness of the session is destroyed in each SSCP along the path. The ses- 
sion setup path 1s established independently for each session between a particular pair of LUs, 
and therefore may involve different intermediate gateway SSCPs for different sessions. 
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Figure 1-22 shows the RUs that follow the path established by CDINIT, the RUs that cause the 
path to be destroyed, and other RUs besides CDINIT that can cause a path to be established. 


RUs that 
determine 
their own 
path 


CDINIT 


(Note 1) 


DSRLST 


(Note) 


Figure 1-22. 


(I, r]Q, Q) 


(SA X'02') 


RUs that follow another RU's path 


Follow and destroy 
path, with RSP sent 
immediately by each 
gateway SSCP 


Only follow path Follow and destroy path 


CDSESSEND (Note 2) 
COTERM( Cleanup ) 

CDSESSSF 
CDSESSTF 


+RSP(CDINIT) 
CDINIT(DQ) 
CDCINIT 
+RSP(CDCINIT ) 
CDSESSST 
RSP(CDSESSST) 
CDTERM 

(not Cleanup) 
+RSP(CDTERM, 


—RSP(CDINIT) 


—RSP(CDCINIT ) 


RSP(DSRLST) 


not Cleanup) 


Session Services RUs and Path Determination: 
Notes: 
1. The following abbreviations are used in the table: 
e I: Initiate only 
e I/Q: Initiate or queue 
e® @Q: Queue only 
® DQ: Dequeue 
e §86SA: Search argument 
2. CDSESSEND, in conjunction with NOTIFY and SESSEND, is used to synchronize SSCPs and 
gateway nodes with respect to session termination. CDSESSEND does not really 


follow the CDINIT path, since it may be generated or discarded in the middle of the 
path. 
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Figure 1-23 illustrates SSCP rerouting through a four-network configuration in which the gateway 
nodes are not explicitly shown. <A CDINIT request for a session between LUI and LU2 could follow 
any of several paths through the set of gateway SSCPs. 


w 
GW SSCP | <————-> | GW SSCP | <———--——-> | GN. SSCP | <---> |GW_ SSCP 
A2 < Bl Cl D1 YT 
A 


A V 
ees 


> 
V GW SSCP] <——>I| SSCP —_ LU2 
<———___ > D2 D4 
>|GW SSCP GW SSCP 

Be —_————— > C2 A 


t — 
LGW SSCPI< 
D3 


NETWORK A NETWORK B NETWORK C NETWORK D 


Figure 1-23. Potential Paths for SSCP Rerouting 


When a gateway SSCP receives an RU for which a path must be sought, it performs a search using 
the data shown in Figure 1-24 on page 1-26. The search may produce the LU's SSCP or a list of 
adjacent gateway SSCPs that can forward the RU one step closer to the LU's SSCP. An adjacent 
SSCP is an SSCP with which the searching SSCP may have a session. The LU's SSCP may or may not 
be a gateway SSCP. If the search returns a list of adjacent SSCPs, the gateway SSCP uses a 
trial-and-error technique to select the next leg of the session setup path. 


Trial-and-error rerouting has two goals: 
e Path-determining RUs may be automatically rerouted around failed nodes and links. 


¢ Gateway SSCPs need not Keep a detailed record of potential end-to-end paths to the SSCP of 
an LU. Instead, they know only the next gateway SSCP on a particular path. 


When a path 1s being sought, a gateway SSCP progresses through the list of adjacent SSCPs in 
order, sending the RU to the next SSCP on the list. If it receives a negative response with 
sense data indicating a rerouting problem, such as resource unknown, it tries the next SSCP on 
the list. When the list is exhausted without success, it returns a negative response with sense) 
data indicating inability to reroute. 


A procedure correlation identifier (PCID) is carried in all session services RUs and is used by 
a gateway SSCP as a key to determine the next SSCP on a previously established path. For a 
description of PCIDs, how they are derived, and why a gateway SSCP may have two for a particular 
session, see "Procedure Correlation Identifier (PCID) Processing" on page 1-27. 


User-defined adjacent gateway SSCP lists may cause a routing loop, where a path-determining RU 
may return to a gateway SSCP that it has already traversed. The SSCP Identifier control vector 
(X'17') on NOTIFY(X'08') and ai Resource Identifier control vector (X'19) on all other 
path-determining RUs contain a "maximum visits" field. If multiple Resource Identifier control 
vectors are present, the one representing the DLU is used. The maximum visits field is initial- 
ized by the first gateway SSCP and decremented by each subsequent gateway SSCP on the path. The 
initial value is installation dependent. If this field is decremented to 0 before reaching the 
target SSCP, it is assumed that a loop in the rerouting path has been detected, and a negative 
response 1s sent. 
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GATEWAY NODE SELECTION 


As CDINIT flows from the SSCP(OLU) to the SSCP(DLU), the first gateway SSCP that sends it across 
each subnetwork boundary or receives it from a non-gateway SSCP across a subnetwork boundary 
selects the gateway node to be used by the LU-LU session to cross that boundary. Alternate 
gateways are available only if the gateway SSCP belongs to multiple parallel gateways that cross 
that boundary. 


After selecting an adjacent SSCP to route to, a gateway SSCP selects a gateway node for the 
LU-LU session from the list of potential gateway nodes associated with the selected SSCP, as. 
shown in Figure 1-24. If the selected SSCP is also a gateway SSCP and itn the same gateway, the 
sending gateway SSCP specifies the gateway node in the Session Initiation control vector (X'14') 
on the CDINIT request. The receiving gateway SSCP negatively responds to the CDINIT if 


° It is required to support the gateway node and does not have an SSCP-PU session with the PU 
of the gateway node, or 


° It is responsible for sending the RNAA RU to that PU and the RNAA fails. 


The gateway node specification is retained in the control vector until the last gateway SSCP in 
the gateway is ready to forward the CDINIT to an SSCP that is not in the gateway. 


CROSS-NETWORK DIRECTORY 


As shown in Figure 1-24, a gateway SSCP may use a system-defined cross-network directory in 
order to perform its rerouting and gateway node selection functions. The directory yields a 
list of adjacent SSCPs to which session-initiation requests concerning a given LU can be routed. 


The granularity of the search is implementation dependent. Gateway SSCPs may always route the 
same way to the same target network, in which case, only the network identifier is needed. If a 
gateway SSCP routes differently to different SSCPs in a particular network, the SSCP name is 
also needed. A gateway SSCP may even route differently to target SSCPs depending on the refer- 
enced LU, in which case the LU name is needed. 


If LU name and SSCP name are both provided, the search first looks for an entry under LU name; 
if none exists, it looks for an entry under SSCP name; if none exists, 1t looks for a general 
entry for that network identifier. 


For each adjacent SSCP in an another subnetwork, the directory includes a list of potential 
gateway nodes that the LU-LU session may use to cross the subnetwork boundary, in order to allow 
the gateway SSCP to select the gateway node for the LU-LU session. 


The cross-network directory described here is an architectural abstraction; the structure is 
not required of implementations. 


Network ID of Target SSCP 
or LU 
> List of adjacent SSCPs list of gateway nodes that may 
Name of Target SSCP or LU including for each SSCP > be used by the LU-LU session 
(optional ) 


Figure 1-24. Data Determining SSCP Rerouting and Gateway Node Selection for LU-LU Sessions 


CONTROL VECTORS CONTAINING GATEWAY RELATED INFORMATION 


The following control vectors contain gateway-related information. They are appended to session 
services RUs sent between current-level SSCPs, i.e., SSCPs that can receive a format 3 CDINIT, 
as specified in the CDRM (X'06) control vector, whether or not they are serving as gateway 
SSCPs. 


° Resource Identifier control vector (X'19') 


The Resource Identifier control vectors on an RU provide the next gateway SSCP with the 
information it needs to perform SSCP rerouting and gateway node selection. 
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Between gateway SSCPs in the first gateway encountered in the session setup path, an LU name 
in a Resource Identifier control vector may be an alias name, rather than the 
network-ID-qualified name normally required; in this case, the control vector indicates 
that the information is tentative. The real names are provided before the RU exits the 
first gateway. See "LU Name Transformation" on page 1-19 for more information. 


Different RUs carry different sets of Resource Identifier control vectors: 
~ In CDINIT and RSP(CDINIT), one each for the OLU and the DLU 


— In NOTIFY(X'06'), i.e., NOTIFY carrying the Cross-Gateway Resource Requested vector, one 
each for the requesting and requested LUs and one for the session partner of the 
requested LU 


— In NOTIFY(X'08'), i.e., NOTIFY carrying the Cross-Gateway Resource Available vector, one 
for the DLU 


—- In DSRLST, one for the LU referenced by the DSRLST 
® NAU Address control vector (X'1A'), appearing in CDINIT and RSP(CDINIT). 


The NAU Address control vector carries the real address of the OLU to the SSCP(DLU) or the 
real address of the DLU to the SSCP(OLU). The network identifier for the address appears in 
the associated Resource Identifier control vector. 


e Session Initiation control vector (X'14') appearing in CDINIT and RSP(CDINIT). 


The Session Initiation control vector carries the class of service (COS) names and the 
transformed mode name. Between multiple gateway SSCPs in the same gateway, it also speci- 
fies the gateway node to be used by the LU-LU session to cross the subnetwork boundary, as 
described itn "Gateway Node Selection" on page 1-26 in more detail. The gateway node name is 
not sent between gateway SSCPs in different gateways. 


e SSCP Identifier control vector (X'17'), appearing in NOTIFY (X'08') only. 


The SSCP Identifier control vector provides the next gateway SSCP with additional informa- 
tion to perform SSCP rerouting. 


PROCEDURE CORRELATION IDENTIFIER (PCID) PROCESSING 


A procedure correlation identifier (PCID) is a session instance identifier used by two SSCPs to 
identify a particular session. Each session services RU contains a PCID field that 1s used by 
gateway SSCPs as a key to the SSCP rerouting data established for a session setup path, as shown 
in Figure 1-25 on page 1-28. 


A procedure correlation identifier 1s unique within a particular subnetwork. A cross-network 
session has a PCID for each subnetwork that it traverses. As a result, each SSCP in the session 
setup path may associate either one or two PCIDs with a session. Gateway SSCPs that send the 
CDINIT request across a subnetwork boundary and are in the middle of the session setup path have 
two PCIDs per session, one each for communicating with the adjacent SSCPs in both directions. 


Before a gateway SSCP sends a CDINIT RU (or other RU that determines its own path, as shown in 
Figure 1-22 on page 1-24) across a subnetwork boundary, it generates a new PCID to replace the 
one in the RU. If the RU is sent to an SSCP in the same subnetwork, the gateway SSCP sends it 
without changing the PCID value. 


The gateway SSCP saves SSCP rerouting data for the session, as shown in Figure 1-25 on page 
1-28, so that it can route subsequent RUs along the same path. The session data includes the 
PCID transform, if one has been established. 


As subsequent requests and responses follow the session setup path, a gateway SSCP uses the PCID 
in the RU as a key to find the session data that identifies the next SSCP to receive the RU. If 
the session data contains two PCID values, the gateway SSCP transforms the PCID value before 
forwarding the RU. 
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if different (OLU side) (DLU side) 


PCID(OLU side) | PCID (DLU side) | | Adjacent SSCP | | Adjacent SSCP | 


Figure 1-25. Data Used to Follow a Session Setup Path and to Transform PCIDs: This figure shows the 


data saved by a gateway SSCP for each session for which a session setup path has been 
established. The items in brackets are optional. For example, if the gateway SSCP is 
the SSCP(OLU), 1t does not have an entry for the adjacent SSCP on the OLU side. 
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All of the components involved in cross-network session initiation maintain appropriate session 
awareness, that 1s, a record of the existence of the LU-LU sessions that are active or in the 
process of being activated or deactivated. The session awareness described here is maintained 
for session services and operator awareness displays, as opposed to any permanent session 
records that might be kept for problem determination. The components that maintain LU-LU ses- 
sion awareness include: 


bd PLU 

e SLU or boundary function representing the SLU 

e SSCPC PLU) 

e SSCP( SLU) 

® All gateway SSCPs on the session setup path 

© All gateway nodes that handle traffic between the two LUs 


Maintenance of session awareness for the PLU, SLU, and non-gateway SSCPs is not changed for 
gateway services. 


Figure 1-26 on page 1-29 shows the events that cause changes in LU-LU session awareness in gate- 
way nodes and gateway SSCPs. This table shows only the events that cause changes in awareness, 
e.g.» receipt of a particular RU; it does not show the RUs sent by these components when the 
events occur. 
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Awareness Changes 


Events for SSCPs on 
Setup Path Cincluding 
gateway SSCPs) 


Events for Gateway 
Nodes 


Adding Session Awareness Sends or receives CDINIT RNAA 


Recognizing Session Sends or receives +RSP( BIND ) 
Activation +RSP(CDSESSST ) 


Destroying Session 
Awareness for the 
following reasons: 


e BIND failure 


Normal session 
deactivation 


UNBIND failure 


Cleanup termination 


Forced termination 
before session active 


LU-LU route 
inoperative 


SSCP—gateway PU 
session outage for 
pending-active 
session only 

(See Note 2.) 


Figure 1-26. Events Causing 


BINDF (for SSCP(PLU) ) 
CDSESSSF (for all others) 
(See note 4.) 


(See Note 1.) 


UNBINDF (for SSCP(PLU)) 
CDSESSTF (for all others) 
(See note 4.) 


Sends or receives 
COTERM( cleanup) 
(See note 4.) 


Sends or receives 
CDTERM(not cleanup) 
when session not active 
(See note 4.) 


(See Note 1.) 


Sends DACTPU or 

detects route inoperative 

for SSCP-PU session to 
gateway node 


Changes in LU-LU Session 


the event "Receives this RU." If either 
first causes the change in session awareness. 


Notes: 


1. For further events 


page 1-30. 


causing changes in SSCP session awareness, 


NOTIFY(X'05') or 
—RSP( BIND ) 


+RSPCUNBIND ) 


NOTIFY(X'05') or 
—RSP(UNBIND } 


NOTIFY(X'05' ) 


NOTIFY(X'05' ) 


Detects LU-LU route 
inoperative 


Receives DACTPU or 
detects route inoperative 
for SSCP-PU session to 

a gateway SSCP 
participating in the 
gateway (See Note 3.) 


Awareness: An RU name by itself represents 
of two events may occur, the one that occurs 


see Figure 1-27 on 


2. A session is pending-active between the time session awareness is added for it (row 
1 in the table) and its activation is recognized (row 2). 


3. <A gateway node recognizes the gateway SSCPs participating in the 


they send it RNAA or SETCV for the session. 


gateway because 


4. Before a gateway SSCP can destroy its own session awareness, one of the following 
must occur for each gateway node that it controls: 


e It has already received NOTIFY(X'05') from the gateway node. 


° It sends NOTIFY(X'05') to the gateway node. 


® . The route connecting it to the gateway node is inoperative. 
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Figure 1-27 shows the rules governing destruction of session awareness in all gateway SSCPs on 
the session setup path when the session terminates normally or because a route becomes inopera- 
tive. Events from both rows 2 and 3 occur before a gateway SSCP destroys its awareness of a 
particular session. An event from row 1 is required only if the gateway SSCP is also the SSCP 
of the PLU or the SSCP of the SLU. 


Which of two adjacent SSCPs in the session setup path sends CDSESSEND depends on timing consid- 
erations governing which one first receives CDSESSEND from the next SSCP in the session setup 
path or first gains direct Knowledge of the session termination from its LU (if it is the SSCP 
of the PLU or SLU) and knows that all its gateway nodes have destroyed their session awareness, 
as described above. An example of the application of these rules is shown in "Deactivation of 


Cross-Network LU-LU Sessions" on page 1-41. 


Events Affecting 
Different SSCPs 


Direct notification 
by an LU: 
SSCP(PLU) or 
SSCP(SLU) 


Direct notification 

by a gateway node: 
any gateway SSCP on 
session setup path 


Knowledge that. each 
neighbor SSCP is. 
directly aware of 
session deactivation: 
any SSCP on 
session setup path 


Normal Notification 


Receives SESSEND 


Receives NOTIFY(X'05') 
or 
Sends NOTIFY (X'05') 


Sends RSP(CDSESSEND ) 
or 
Receives RSP(CDSESSEND ) 


Route Loss Notification 


Detects route inoperative for SSCP-LU session 


Detects route inoperative for SSCP—-PU session 
(to gateway node) 


Detects route inoperative for SSCP-SSCP 
session (failure between SSCP and gateway) 
or 
Receives DACTCDRM 
(failure in adjacent subnetwork ) 
or 


Receives CDTERM (cleanup) 
(failure further down session setup path) 


Figure 1-27. Release of an SSCP's LU-LU Session Awareness: "Normal notification” means that an SSCP 


learns directly from a session partner about the session deactivation. "Route loss 
notification’ means that the route connecting an SSCP to its session partner is 
inoperative, so that the SSCP cannot learn of any changes in session status from that 
session partner. It may also mean that a failure has occurred further down the session 
setup path, so that the SSCP cannot learn of the session status from either the 
SSCP(PLU) or SSCP(SLU). 
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GATEWAY SSCP FUNCTIONS 

Gateway SSCPs perform the following gateway-related functions in addition to their other SSCP 
functions: 

e Activating cross-network SSCP-SSCP sessions 


® Rerouting session services RUs received from one SSCP to the next SSCP on the session-setup 
path 


e Supporting testing of routes and route status reporting for routes in other subnetworks 
® Session services to support cross-network LU-LU sessions, including the steps listed below. 


If a gateway contains a single gateway SSCP, it fulfills the roles of the gateway SSCPs on 
both the OLU and DLU sides of the gateway. If a gateway contains multiple gateway SSCPs, 
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the list shows which one performs the particular function. Unless otherwise noted, these 
functions are performed for every gateway in the session setup path. 


~- Selecting the gateway node to be used to cross the subnetwork boundary—done by the 
first gateway SSCP that sends a CDINIT across a subnetwork boundary in each gateway 


- Transforming alias DLU name to real DLU name in session services RUs—done by any gate- 
way SSCP in the first gatenay 


- Transforming real OLU name to alias OLU name—done by any gateway SSCP along the session 
setup path 


- Transforming mode names appearing in session services RUs—done by any gateway SSCP 
along the session setup path 


- Transforming COS names appearing in CDINIT requests—done by the gateway SSCP along the 
session setup path that transformed the DLU alias name to the network-ID-qualified DLU 
name 


- Transforming COS names appearing in CDINIT responses—done by one gateway SSCP in each 
gateway 


- Sending RNAA and SETCV to the gateway node to request resources for a session and to set 
up the address transform—done by predesignated gateway SSCP or gateway SSCP on the DLU 
side 


- Resolving the COS name to a VR identifier list and sending the list to the gateway node 
in a SETCV—done by predesignated gateway SSCP or the gateway SSCP on the OLU side 


- Sending SETCV with the LU name transform—done by predesignated gateway SSCP or gateway 
SSCP on the OLU side 


- Sending SETCV to the gateway node to indicate its own participation in the session set- 
up—done by any gateway SSCP that has not otherwise sent SETCV or RNAA to the gateway 
node 


- Generating a new PCID to insert in CDINIT;, DSRLST, NOTIFY(X'06'), or NOTIFY(X'08' )—done 
by every gateway SSCP on the path that sends the RU across a subnetwork boundary 


—- Transforming PCIDs—done by every gateway SSCP that sends a CDINIT request across a sub- 
network boundary 


~ Maintaining session awareness and an associated rerouting path until session termination 
events occur (see "LU-LU Session Awareness Maintained by Gateway Components" on page 
1-28)—-done by every gateway SSCP 
- Cleaning up affected pending-active or pending-reset cross-network LU-LU sessions before 
deactivating its session with another SSCP—done by every gateway SSCP 
GATEWAY NODE FUNCTIONS 


This section outlines the functions performed by the gateway PU and the two components of a 
gateway function component. 


Gateway PU Functions 


Gateway-related RUs reach the gateway node over an SSCP-PU session. The gateway PU passes these 
RUs to the gateway function session manager for processing, and forwards responses and other RUs 
from the gateway function session manager to the gateway SSCP. 

On receipt of a gateway-related RNAA request, the gateway PU assigns two alias addresses for the 
session before passing the request on to the gateway function session manager. 


Gateway Function Session Manager Functions 


The gateway function session manager manages the creation and destruction of session connectors. 
This function involves: 
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e Reserving resources for a session connector on receipt of an RNAA request from the gateway 
PU and associating these resources with the addresses in the RNAA 


e §€Forwarding session-activation and -deactivation requests and responses received from one 
subnetwork to a NAU in another subnetwork, with the following transformations: 


- Addresses in the transmission header are transformed according to the address transform 
received in earlier RNAA and SETCV requests. | 


- Names appearing tn BIND requests and responses are transformed according to the name 
transform received in a SETCV request. 


® Activating a virtual route in the subnetwork on the secondary-NAU side of the gateway node, 
using a virtual route identifier list received in an earlier SETCV request 


® Freeing resources reserved for session connectors when requested by the PU 


® Sending REQACTCDRM to an SSCP when necessary for SSCP-SSCP session activation as described 
in "Activation of Cross-Network SSCP-SSCP Sessions" on page 1-34 


® Creating and initializing the session connector and connecting it to the associated path 
controls. The address transform associated with the session connector contains two address » 
pairs; the session manager gives one address pair to one path control and one to the other. 


e 6©Keeping track of the gateway SSCPs involved with a particular session connector, i.e.) the 
ones that sent RNAA or SETCV concerning that session; removing SSCPs from the list when 
they send DACTPU or when the route for the SSCP-PU session becomes inoperative 


e Sending NOTIFY(X'05') to the SSCPs involved with a session connector (see above) when LU-LU 
sessions are started or ended | 


® Recognizing when session connectors should be destroyed, including all session-outage 
notification (SON) conditions (for example, session connectors for pending-active sessions 
are destroyed when an SSCP-PU session between the gateway PU and a participating gateway 
SSCP is lost) 


®  Disconnecting the session connector from both path controls and destroying it 


e Sending a session-deactivation request to a NAU in one subnetwork if the virtual route to 
its session partner in another subnetwork is lost 


® Deactivating a session if a gateway SSCP sends a NOTIFY(X'05') requesting that the session 
resources be released 


© Resolving ACTCDRM contention and SSCP-SSCP session override for cross-network sessions. See 
SNA Format and Protocol Reference Manual: Architecture Logic for a description of these 


ES EO EEE EGER SERRE ERERSEED = TRUM Tae EET ET 


functions. 
® Maintaining LU-LU session awareness until session termination events occur (see "LU-LU Ses- 
sion Awareness Maintained by Gateway Components" on page 1-28) 


Gateway Function Session Connector Functions 


A gateway function session connector receives message units from one path control and sends them 
via the other. It forwards message units in the order it receives them; it does not change the 
order based on the expedited flow indicator. It may also collect accounting data, if required, 
in an implementation- and installation-defined fashion. 
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SUMMARY OF GATEWAY FUNCTIONS RELATED TO LU-LU SESSIONS 


Figure 1-28 shows the allocation between gateway SSCPs and gateway nodes of major functions with 
respect to cross-network LU-LU sessions. 


———>]| Gateway SSCP |<———__—__ 


Name transformation within RU 
Address transformation within 
RU 
PCID transformation within RU Gateway 
Resolving COS name to VR list Node 
SSCP rerouting on another 

SSCP—SSCP session 


— 


Forwarding RUs from one LU 

to an LU in a different subnetwork 
Requesting a virtual route 

in the subnetwork of the SLU 

TH address transformation 

Name transformation in BIND only 


Figure 1-28. Location of Major Gateway Functions with Respect to LU-LU Sessions. 
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The figures below show the exchange of message units among components involved in cross-network 


sessions. 


See Appendix N for an explanation of the notation used in the flows. 


ACTIVATION OF CROSS-NETWORK SSCP-SSCP SESSIONS 


The following three figures show the activation of cross-network SSCP-SSCP sessions in different 


configurations. 


dik eee A aise B 


GATEWAY GATEWAY GATEWAY OR 


NON-GATEWAY 
SSCP SSCP 


RNAA 
ee o 
+RSPCRNAA) 
SETCV(CV X15", X'IA", X'1B", X'1B') 
ne > oO 
+RSPCSETCV) 
| ° 
ACTCDRM(CV X'06', X'09', X'13°, X'18') 
+RSPCACTCDRM; CV X'06', X'09'», X'13", X'18') -- See note. 


session traffic 


Figure 1-29. Cross-Network SSCP-SSCP Session Activation by a Gateway SSCP: 
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Note: Control vectors X'13' and X'18' are not-appended to a RSP(ACTCDRM) sent by a 


non-gateway SSCP. 


In Figure 1-29, the SSCP initiating the session is a gateway SSCP, which sends RNAA (1) and 
SETCV (3) to the gateway node in order to set up the address transform for the session before it_ 
sends ACTCDRM (5). 


Before sending ACTCDRM, the gateway SSCP acquires a virtual route in its opm network. The gate- 
way node acquires a virtual route in the second network before forwarding the ACTCDRM (5). 
Although the SETCV carries: two virtual route lists (control vector X'1B'), one for each subdnet- 
work, only the route list corresponding to the second subnetwork is used. The purpose of send- 
ing two lists is to allow the ACTCDRM to come from either SSCP; the gateway node is prepared to 
acquire a route in either network. 
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NETWORK A NETWORK B 
fe ra ee ea Ne ee ee ee et ay 


GATEWAY GATEWAY NON-GATEWAY 
SSCP NODE SSCP 


ACTCDRM 
e< 
REQACTCDRM 


-RSPCACTCDRM, SD X'0881') 


Figure 1-30. Cross-Network SSCP-SSCP Session Activation by a Non-Gateway SSCP: See Figure 1-29 for 
the steps that follow step 3. 


In Figure 1-30, the SSCP initiating the session is not part of the gateway, and therefore does 
not send the preliminary RNAA and SETCV requests required to prepare the gateway node for the 
cross-network session. It sends an ACTCDRM request to the gateway node (1), which responds neg- 
atively (3). The gateway node matches the alias address in the ACTCDRM request with a gateway 
SSCP name, and then determines if it has an active session with that SSCP. If so, it sends the 
gateway SSCP a REQACTCDRM request (2), informing it that an SSCP in another network desires a 
session with it. The gateway SSCP then initiates the session in the normal manner, as shown in 
Figure 1-29 on page 1-34. 
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NETWORK A NETWORK B NETWORK C 
Pree tg OAT NE Se ee gg pe ee TE SQ ge a ae eee iy ee ee ray 


GATEWAY GATEWAY GATEWAY GATEWAY 


SSCP NODE NODE SSCP 
ol ; 1 2 | 2 
RNAA 
lo ° © erence @ 
RSP(RNAA ) 
2 0 o | nrc > @ 
SETCV(CV X'15", X'1A', X'IB', X'1B') 
3 Oo oO o—__________- © 
RSP(SETCV) 
q re} Oo ee | 
ACTCDRM(CV X'06', X'09', X'13', X'18" ) 
5 Oo BC ercererereremnncr seme monnencmranmnerearvememmeranracnoy GY raesmarersmceemnernemesmowmemeanrnnnsiensemestimrses Ai 
REQACTCDRM 
6 e re) ° 
-RSPCACTCDRM, SD X'0881" ) 
7 Oo oe 
RNAA 
8&8 °® >e re) re) 
+RSPCRNAA ) 
9 © o | o 
SETCV(CV X'15', X'1A', X'1B', X'1B") 
10 ¢ 2>e o ° 
+RSP(SETCV) 
ll e< e © ve) 
ACTCDRM(CV X'06', X'O9', X'13', X'18') 
12 @ Deets > Onteniente > @ 
+RSPCACTCDRM; CV X'06', X'09', X'13', X'18') 
13 e< ° 
session traffic 
14 e< >e 
Figure 1-31. Cross-Network SSCP-SSCP Session Activation, Maximum Separation 
Figure 1-31 shows the activation of a session between two gateway SSCPs with two gateway nodes 
between them (see Figure 1-10 on page 1-10). Gateway SSCP 2 sets up the address transform for 
the SSCP-SSCP session with 1ts neighboring gateway node by sending RNAA and SETCV (1, 3). It 
then acquires a virtual route in network C and sencs the ACTCDRM request (5). Gateway node 2 
acquires a virtual route in network B and forwards the ACTCDRM to gateway node 1, being unable 
to distinguish it from the target SSCP itself (5). Since gateway node 1 does not have a com- 
plete address transform for the session, it negatively responds to the ACTCDRM (7) and sends 
REQACTCDRM to the target gateway SSCP (6) in exactly the manner illustrated in Figure 1-30 on 
page 1-35. 
When gateway node 2 receives the negative response to ACTCDRM (7), 1t can tell from the sense 
code that the other gateway SSCP will be initiating the session. Therefore, it retains the 
address transform set up earlier in anticipation of an ACTCDRM request from the gateway SSCP in 
subnetwork A. It releases the virtual route in network B that it acquired earlier (5). Gateway 
SSCP 2 releases the virtual route in network C when it receives the negative response. 
The session activation then proceeds, with the gateway SSCP in subnetwork A sending RNAA and 
SETCV (8, 10) to gateway node 1 and acquiring the virtual route in network A (12), gateway node 
1 acquiring the virtual route in network B (12), and gateway node 2 acquiring the virtual route 
in network C (12). 
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ILU GATEWAY GATEWAY GATEWAY SSCP(DLU) 
SSCP NODE SSCP 


INIT—SELF | INIT—OTHER 
0 rece eeeere > @ o °o 
CDINIT (CV X'IA', X'14", X'19", X'19") 
ree > D 
RNAA 
re] eo ——________—____———- 
+RSP(RNAA ) 
o O rrr ennreremnenncnes > @ 
CDINIT 
° ° bd 


+RSP(CDINIT } 


°o o e< 
SETCV(CV X'15', X'IA') 
oO e<——__-__________--_-_— © 
+RSPCSETCV) 
oO >_> © 
+RSP(CDINITs CV X'1A', X'14", X'19', X'19") 
errr eeaewecee 
SETCV(CV X'15', X'16'», X'1B") 
e—______________ > ® o 
+RSP(SETCV ) 
<< ————_—_— 6 oO re) 
+RSPC INIT) 

<8 re) oO re) 


Figure 1-32. LU-LU Session Initiation: This sequence is not affected by the PLU/SLU polarity of the 
LU-LU session. It is followed by the LU-LU session setup sequence (see Figure 1-34 on 
page 1-39), which does depend on the PLU/SLU polarity. 


LU-LU SESSION INITIATION 


The initiating LU (ILU) sends the SSCP in its domain an INIT-SELF or INIT-OTHER request (1). It 
receives a response from its SSCP (12) after its SSCP receives the CDINIT response (9). 


In Figure 1-32, the SSCP of the ILU is also the SSCP of the OLU. 


The SSCP of the ILU sends a CDINIT request to the SSCP of the DLU (2, 5). The session setup 
path is established as this RU flows from the SSCP of the OLU to the SSCP of the DLU. Between 
gateway SSCPs, this request and tts response are required to carry gateway control vectors, as 
described in "Control Vectors Containing Gateway Related Information" on page 1-26. 


The gateway SSCP on the DLU side of each gateway sends an RNAA request to the gateway node, 
requesting it to assign alias addresses for the LU-LU session (3). The gateway node returns the 
alias addresses (4). 


The CDINIT response contains the real address of the DLU (6, 9). The gateway SSCP on the DLU 
side conveys this address to the gateway node in the X'1A' control vector of the SETCV request 
(7). 


The gateway SSCP on the OLU side of a gateway resolves the COS name for the SLU side of the 


gateway to a VR identifier list, and sends the list (control vector X'1B'), along with the LU 
name transform (control vector X'16') to the gateway node in a SETCV request (10). 
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ILU/ SSCP GATEWAY | GATEWAY GATEWAY SSCP | DLU 
OLU (OLU) SSCP | NODE SSCP (DLU) 


INIT—SELF | INIT—OTHER 
e@ 


1 >e ve) fe) ° ve] re) 
CDINIT(I/Q) 
2 re) © ee eeneerereneneeereevenerneneee > @ ve) fe) fe ° 
CDINIT(I|Q; CV X'1A', X'14', X'19", X'19") 
3 ° ° © a ne > o ° 
RNAA 
& ° ° ° e<——_____-______—- @ ve) ° 
+RSPCRNAA) 
5 e) ° ° ——___________ > re) ° 
CDINIT(1]Q) 
6 ° fe) fe) fe) © renee > © fe) 
+RSP(CDINIT; Q) 
7 fe) fe) fe) ve) © en @ ° 
SETCV(CV X'15', X'IA') 
8 ° e) re) Onn © s) re) 
+RSPCSETCV) 
9 ° e) ° —————_$______—->® ° ° 
+RSP(CDINIT; Q, CV X'IA',s X'14', X'19", X°'19') 
10 re) e KO ° re) 
SETCV(CV X'15') 
ll fe) ° © renee > @ fe) te) fe) 
+RSPCSETCV } 
12 fe) ° dp comeeneemmmememied ° ° fe) 
+RSP(CDINIT; Q) 
13. Oo e<—____________— © ° ° ° ° 
+RSPCINIT* ) 
14 o<-———* | re) ve) o fe) fe) 
(some time later) 
CDINIT(DQ) 
15 o ® a, | a | re 
SETCV(CV X'15', X'16', X'1B') 
16 o fe) ¢—______—_-- > © ° ° ° 
+RSP( SETCV) | 
17 o o <——_—_—_—-—— © fo) ve) o 
CDINIT(DQ) 
18 o en ® ° re) ° ° 
+RSP(CDINIT; DQ) 
19 o 0 > 0 5 re 
Figure 1-33. CDINIT Queuing and Dequeuing Through a Gateway 
CDINIT QUEUING 
As shown in Figure 1-33, a CDINIT can cause a request for session resources to be queued at the 
SSCP of the DLU, if the CDINIT request indicates that the session should be initiated or queued 
(I/Q) and the resources for the session are not available when the CDINIT is received. In that 
case, the address transform is set up when the first CDINIT flows (4, 5, 8, 9). The gateway 
SSCP on the OLU side sends SETCV to the gateway PU to indicate its participation in the session 
setup so that it can be notified when the session status changes (11). 
When the resources become available, the SSCP of the DLU sends a dequeue CDINIT(DQ) to the SSCP 
of the OLU to complete the initiation phase of session establishment (15, 18). This RU follows 
the session setup path set up by the earlier CDINIT and uses the address transform already 
established. This phase is followed by the session setup phase, which is shown In Figure 1-34 
on page 1-39. 
The name transform and VR identifier list are sent to the gateway node (16) after after the 
dequeue CDINIT 1s processed (15). 
1-38 Systems Network Architecture Format and Protocol Reference Manual: SNA Network Interconnection 


PLU GATEWAY GATEWAY GATEWAY SSCP(SLU) SLU 
SSCP NODE SSCP 


e< 


COCINIT 


+RSPCCDCINIT ) 


CINIT 


Oo 


+RSP(CINIT) 


fe) 
BIND 


+RSP(BIND ) 
° 


SESSST 
Oo °o oO eo< 
NOTIFY(X'05', CV X'15", X'1E', X'15', X'I1E') 
OT eee re) re) 
NOTIFY(X'O05', CV X'15', X'1LE', X'I5', X'1E') 
° ¢—_____—-—----_ > ® ° 
SESSST 
>@ fe) ° ° 
CDSESSST 
DO ences > @ oO 


RSP(CDSESSST ) 
rere enceneenceeemenemenncenmesemmmeneess OP emeseeeneeenencmmeoumenmemneceenccns Gp oO 


1-34. LU-LU Session Setup: This sequence is affected by the PLU/SLU polarity of the LU-LU | 
session. It follows the LU-LU initiation sequence shown in Figure 1-32 on page 1-37. 


LU-LU SESSION SETUP 


The SSCP of the SLU sends CDCINIT containing session parameters for the BIND image (1). This 
request follows the session setup path established for the session in Figure 1-32 on page 1-37. 


The SSCP of the PLU sends a CINIT request with the BIND image to the PLU (3). 


After a successful exchange of BIND RUs (5, 6) the SLU and the PLU each send SESSST RUs to their 
SSCPs (7, 10). If the SLU is in a peripheral node, boundary function sends SESSST on its 
behalf. The SSCP of the PLU sends CDSESSST to the SSCP of the SLU along the session setup path 
(11). The SSCPs update their session awareness records to show that the session is active, as 
shown tn Figure 1-26 on page 1-29. 


The gateway node notifies all gateway SSCPs in its gateway that the session has started (8, 9). 


The NOTIFY(X'05') RU carries two VR-ER Mapping Data (X'1lE') control vectors, identifying the 
virtual route used for the session in both networks. 
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Network 1 Network 2 


SLU SSCP GATEWAY GATEWAY SSCP PLU 
SSCP SSCP 


DACTCDRM (or route connecting them inoperative) 


1 ° o—____________-— > @ a.) ° re) 
: COTERM( cleanup ) 
2 o re) $$$ > & > ® ° 
+RSP(DACTCDRM) ° 
3 oOo <0 ° ° 
| CLEANUP | 
G re) re} re re} Ore > @ ee.8e 


Figure 1-35. Deactivation of a Cross-Network SSCP-SSCP Session 


DEACTIVATION OF CROSS-NETHORK SSCP-SSCP SESSIONS 


Figure 1-35 shows the actions of a gateway SSCP on receiving a DACTCDRM request or on learning 
that the route connecting it to another SSCP is tnoperative (1). It resets all pending-active 
and queued LU-LU sessions associated with its session partner. 


The figure shows only the cases where the PLU and gateway SSCP are in different subnetworks. If 
they are in the same subnetwork, normal takedown procedures described in SNA Format and Protocol 
Reference Manual: Architecture Logic take place. 


For each LU-LU session with a PLU in a different subnetwork, the gateway SSCP sends 
CDTERM(cleanup) to the SSCP of the PLU (2), prompting it to send CLEANUP to the PLU (4). 


The gateway SSCPs receiving the CDTERM(cleanup) immediately destroy the session setup path asso- 
ciated with the session. 
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PLU GATEWAY GATEWAY GATEWAY SSCP(SLU) SLU 
SSCP(PLU) NODE SSCP 
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14 


15 


TERM*(Orderly| Forced) 


ce] ve) re) re) 6 
+RSP( TERM ) 
oO ° re) re) ——_—-__—————- > 6 
COTERM( Orderly| Forced) 
ro) nn ey ro) 
RSP(COTERM) 

re) e > eT | Oo 
CTERM( Orderly | Forced) 

<< © ° ° ° ° 

+RSP(CTERM) 
e > oO o @] 
UNBIND 
@ re 
+RSP(UNBIND ) 
o< a eS ee a TT 
NOTIFY(X'05', CV X'15') 
oO ve) ——________—__—— > @ fe] oO 
NOTIFY(X'O05', CV X'15') 
re) °<—__________—_——- © oO °o oO 
CDOSESSEND 
oO << ° re) 
CDSESSEND 
re) re) ° > 0 ve] 
+RSP(CDSESSEND ) 
re) D ocr recta en arr erntemaeneernarenemneremancnrenanercsramaascancaraeacenece > re) oO 
+RSP(CDSESSEND } 
o ° re) Ore © ° 
SESSEND SESSEND 

@ caer nremnnnmmenemmemmmae > @ re) oO errr @ 


Figure 1-36. LU-LU Session Deactivation 


DEACTIVATION OF CROSS-NETWORK LU-LU SESSIONS 


Figure 1-36 gives an example of the deactivation of a cross-network LU-LU session. In this 
case, the SLU starts the procedure by sending a TERM-SELF or TERM-OTHER RU, and a cross-network 
CDTERM is sent to the SSCP of the PLU (3). In the case of the PLU sending TERM-SELF or 
TERM-OTHER, the UNBIND is the first cross-network RU. 


After the exchange of UNBIND RUs (7, 8), the gateway node sends NOTIFY to its gateway SSCPs (9, 
10). The Network-Qualified Address Pair (X'15') control vector on the NOTIFY RU identifies the 
terminated session. As soon as it receives the NOTIFY, the gateway SSCP on the SLU side sends 
CDSESSEND to its neighboring SSCPs (11, 12). The gateway SSCP on the PLU side receives the 
CDSESSEND before it is ready to send CDSESSEND (11), and responds immediately (13). 


The gateway SSCP on the PLU side releases its session awareness when tt has received NOTIFY from 
the gateway node (10), SESSEND from the PLU (15), and CDSESSEND from its adjacent SSCP (11). 
The gateway SSCP on the SLU side releases its session awareness when it has received NOTIFY from 
the gateway node (9) and responses to CDSESSEND from both neighboring SSCPs (13, 14). 
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APPENDIX E. REQUEST-RESPONSE UNIT (RU) FORMATS 


rere 


This appendix defines detailed RU formats. A categorized list of RU abbreviations is presented 
first, followed by an alphabetic list of request RU format descriptions, a summary of response 
RUs, and a list of response format descriptions for those positive response RUs that return data 
in addition to the request code. Two final sections describe control vectors, control lists and 
session Keys, which are used in multiple RUs. 


The initial line for each RU in the two RU format description lists is in one of ‘the following 
formats: 


Requests 


"RU ABBREVIATION; Origin NAU-->Destination NAU, Normal (Norm) or Expedited (Exp) Flow; RU Cate- 
gory (RU NAME)" 


Responses 
"RSPCRU ABBREVIATION); Origin NAU-->Destination NAU, Norm or Exp Flow; RU Category" 
Notes: 
1. "RU Category" is abbreviated as follows: 
Sc session control 
NC network control 
FMD NS(c) function management data, network services, configuration services 
FMD NS(ma) function management data, network services, maintenance services 
FMD NS(s) function management data, network services, session services 
2. The formats of character-coded FMD NS RUs are implementation dependent. 
3. All values for field-formatted RUs that are not defined in this section are reserved. 
4. The request code value X'FF' and the NS header values X'(3/7IBIF )Fxx**'" = and 
X'**(3171BIF )F%*' are set aside for implementation internal use, and will not be otherwise 
defined in SNA. 
5. Throughout this appendix the following symbol-string types are used: 
¢ Symbol-string type A (Assembler oriented): a byte string consisting of one or more 
EBCDIC upper-case letters (A through Z), numerics (0 through 9), $, #, and 2, the first 
character of which is nonnumeric. 

e Symbol-string type USS ("Unformatted System Services" or character-coded subset of the 
SNA character set): a byte string consisting of one or more EBCDIC upper-case letters 
(A through Z), numerics (0 through 9), $, #, 3, line feed (X'15'), space (X'40') and the 
following 11 special characters: '=(),+-*./& with no restriction on the first character. 

®  Symbol-string type AE (A extended): a byte string consisting of one or more EBCDIC 
lower-case letters (a through 2), upper-case letters (A through Z), numerics (0 through 


9), $5 #, 3, and period (.), with no restriction on the first character. 


®  Symbol-string type GR (EBCDIC graphics): a byte string consisting of one or more EBCDIC 
characters in the range X'41' through X'FE', with no restriction on the first character. 


e  Symbol-string type G (general): a byte string consisting of one or more bytes of binary 
values 0 through 255. 


The variable to which a type-A, type-AE, or type-GR symbol string is assigned may be longer 
than the symbol string; in this case, the symbol string is left-justified within the field, 
which is filled out to the right with space (X'40') characters. Space characters, 1f pres- 
ent, are not part of the symbol string. If the symbol string is formed from the concat- 
enation of two or more individual symbol strings, such as the fully-qualified LU name, the 
concatenated symbol string as a whole is left-justified within the field, which is filled 
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out to the right with space characters. Space characters, if present, are not part of the 
concatenated symbol string. 


Throughout this appendix, reserved is used as follows: reserved bits, or fields, are cur- 
rently set to O's (unless explicitly stated otherwise); reserved values are those that cur- 
rently are invalid. Correct usage of reserved fields is enforced by the sender; no receive 
checks are made on these fields. 


Throughout this appendix, retired fields and values are those that were once defined by SNA 
but are no longer defined. To accommodate implementations of back-level SNA, current imple- 
mentations of SNA treat retired fields as follows: send checks enforce the setting of 
retired fields to all 0's except where other unique values are required (described individ- 
ually in this appendix); no receive checks are made on these fields, thereby accepting 
back-level settings of these fields. Special handling of retired fields, such as echoing or 
passing on retired fields as received, is discussed where appropriate. 
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SUMMARY OF REQUEST RU'S BY CATEGORY 


sc 
¥ACTCDRM *BIND 
*ACTPU DACTCDRM 
NC 
NC-ER-TEST-REPLY 
FMD NS(c) 
CONTACTED REQACTCDRM 
NOTIFY *RNAA 
FMD NS(ma) 
ER-TESTED *ROUTE-TEST 
FMD NS(s) 
BINDF CDSESSTF 
CDCINIT *CDTERM 
*CDINIT *xCINIT 
CDSESSEND CLEANUP 
CDSESSSF CTERM 
CDSESSST 


* These request RUs require response RUs that, 


DACTPU 


ROUTE-INOP 


*DSRLST 
JNIT-OTHER 

*1NIT-OTHER-CD 
INIT-SELF 
NOTIFY 


UNBIND 


SETCV 


SESSEND 
SESSST 
TERM-OTHER 
TERM-SELF 
UNBINDF 


if positive, may contain data in addition to the NS 


header or request code. See "Summary of Response RU's" on page E-43 and "Positive Response RU's with 


Extended Formats" on page E-43. 
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Within NC, SC, or any specific FMD NS category, the request code is unique. However, while a request 
code has only one meaning in a specific category, a given code (e.g., X'05') can represent different 
requests in separate categories (e.g., NC, and configuration services). DSRLST, NOTIFY, and SETCV are 
exceptions: these three requests have request codes--X'27', X'20', and X'1ll', respectively--that are 
unique across all the FMD NS categories. 


FMD NS Headers (Third byte is the request code) 


X'010211' SETCV (FMD NS(c)) 
X'010280' CONTACTED 
X'010681' INIT-SELF (Format 0) 
X'010683' TERM-SELF (Format 0) 
X'410210' RNAA | 
X'410220' NOTIFY (SSCP-->PU, PU-->SSCP) 
X'410289' ROUTE-INOP 
X'41028A' REQACTCDRM 
X'410307' ROUTE~TEST 
X'410386' - ER-TESTED 
X'810601' CINIT 
X'810602' CTERM 
%'810620' NOTIFY (SSCP<-->SSCP, SSCP-->LU) 
%'810629' CLEANUP 
%'810680' INIT-OTHER 
X'810681' INIT-SELF (Format 1) 
X'810682' TERM-OTHER 
X'810683' TERM-SELF (Format 1) 
X'810685' BINDF 
X'810686' SESSST 
X'810687' UNBINDF 
X'810688' SESSEND 
%'818627' DSRLST 
X'818640' INIT-OTHER-CD 
X'818641' CDINIT 
X'818643' COTERM 
X'818645' CDSESSSF 
X'818646' CDSESSST 
X%'818647" CDSESSTF 
X'818648' CDSESSEND 
X'81864B' COCINIT 
SC Request Codes 
Xx'11' ACTPU 
X'12' DACTPU 
X'14' ACTCDRM 
x'15' DACTCDRM 
xX'31' BIND 
X'32' UNBIND 


NC Request Codes 


X'OA' 


REQUEST RU FORMATS 


NC-ER-TEST-REPLY 


ACTCDRM; SSCP-->SSCP, Exp; SC (ACTIVATE CROSS-DOMAIN RESOURCE MANAGER ) 


ACTCDRM is sent from one SSCP to another SSCP to 


activate a session between them and = to exchange 
information about the SSCPs. 


0 X'14' request code 
l bits 0-3, format: X'0" Conly value defined) 
bits 4-7, type activation requested: 
X'1' cold 
X'2' ERP 
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18 


19-n 


ACTCDRM 


FM profile 

TS profile 

Contents ID: eight-character EBCDIC symbolic name that represents implementation and 

installation dependent information about the SSCP issuing the ACTCDRM; eight space 

(X'40') characters is the value used if no information is to be conveyed (This field 

could be used to provide a check for a functional and configurational match between 

the SSCPs.) 

SSCP ID: a six-byte field that includes the ID of the SSCP issuing the ACTCDRM; the 

first four bits specify the format for the remaining bits: 

bits 0-3, format 0000 (only value defined) 

bits 4-7, physical unit type of the node containing the SSCP 

bits 8-47, implementation and installation dependent binary identification 

TS Usage 

bits 0-1, reserved 

bits 2-7, primary CPMGR receive window size (0 means no pacing of requests flowing to 
the primary) 

One or more control vectors, as described in the section "Control Vectors" on page 

E-49 

Note: The following vector Keys may be used in ACTCDRM: 

X'06" CDRM control vector 

X'09' Activation Request/Response Sequence Identifier control vector 

X'13' Gateway Support Capabilities control vector 

X'18' SSCP Name control vector 


ACTPU; SSCP|PUCP-->PU, Exp; SC (ACTIVATE PHYSICAL UNIT) 


3-8 


Note: 


9-n 


ACTPU is sent by the SSCP to activate a session 


with the PU, and to obtain certain information 
about the PU. 


X'1ll' request code 
bits 0-3, format: 
X'O' Format 0 
X'3' Format 3—same as Format 0, except that it always includes one or more 
control vectors in bytes 9-n (sent only to PU_T4¢I5s that support ERs 


and VRs) 
bits 4-7, type activation requested: 
X'1' cold 
X'2' ERP 


bits 0-3, FM profile: 
X'O' FM profile 0 
X'5' FM profile 5 
bits 4-7, TS profile: 
X'l' TS profile 1 
X'S' TS profile 5 
A six-byte field that specifies the ID of the SSCP issuing ACTPU; the first four bits 
specify the format for the remaining bits: 
bits 0-3, format: 0000 (only value defined) | 
bits 4-7, PU type of the node containing the CP 
bits 8-47, implementation and installation dependent binary identification 


End of Base Format 


One or more optional control vectors, as described in the section "Control Vectors" on 
page E-49 

Note: The following vector keys may be used in ACTPU: 

X'09' Activation Request/Response Sequence Identifier control vector 

X'0B' SSCP-PU Session Capabilities control vector 

X'18' SSCP Name control vector 


BIND; PLU-->SLU, Exp; SC (BIND SESSION) 


— 


BIND is sent from a.primary LU to a secondary LU 
to activate a session between the LUs. The sec- 


ondary LU uses the BIND parameters to help deter- 
mine whether 1t will respond positively or 
negatively to BIND. 


X'31' request code 

bits 0-3, format: 0000 (only value defined) 

bits 4-7, type: 
0000 negotiable (only value defined for LU 6.2) 
0001 nonnegotiable 

FM profile: 

X'02' FM profile 2 
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X'03' FM profile 3 

X'04' FM profile 4 

X'0O7' FM profile 7 

X'12' FM profile 18 

X'13' FM profile 19 (only value defined for LU 6.2) 
3 TS profile: 

X'02' TS profile 2 

X'03' TS profile 3 

X'04' TS profile 4 

X'07' TS profile 7 (only value defined for LU 6.2) 

FM Usage—Primary LU Protocols for FM Data 
4 bit 0, chaining use selection: 

0 only single-RU chains allowed from primary LU half-session 

1 multiple-RU chains allowed from primary LU half-session (only value defined 
for LU 6.2) 

bit 1, request control mode selection: 
0 immediate request mode (only value defined for LU 6.2) 
1 delayed request mode 
bits 2-3, chain response protocol used by primary LU half-session for FMD requests; 
chains from primary will ask for: 
00 no response 
01 exception response 
10 definite response 
11 definite or exception response (only value defined for LU 6.2) 
bit 4, 2-phase commit for syne point (reserved if any TS profile other than 4): | 
0 2-phase commit not supported 
1 2-phase commit supported 
bit 5, reserved 
bit 6, compression indicator (reserved for LU 6.2): | 
0 compression will not be used on requests from primary 
1 compression may be used 
bit 7, send End Bracket indicator: | 
0 primary will not send EB (only value defined for LU 6.2) 
1 primary may send EB 
5 bit 0, chaining use selection: 

0 only single-RU chains allowed from secondary LU half-session 

1 multiple-RU chains allowed from secondary LU half-session (only value 
defined for LU 6.2) 

bit 1, request control mode selection: 
0 immediate request mode (only value defined for LU 6.2) 
1 delayed request mode 
bits 2-3, chain response protocol used by secondary LU half-session for FMD requests; 
chains from secondary will ask for: 
00 no response 
01 exception response 
10 definite response | 
11 definite or exception response (only value defined for LU 6.2) 
bit 4, 2-phase commit for syne point (reserved if any TS profile other than 4): 
0 2-phase commit not supported 
1 2-phase commit supported 
bit 5, reserved 
bit 6, compression indicator (reserved for LU 6.2): 
0 compression will not be used on requests from secondary 
1 compression may be used 
bit 7, send End Bracket indicator: 
0 secondary will not send EB (only value defined for LU 6.2) 
} secondary may send EB 
FM Usage—Common LU Protocols 
6 bit 0, session segmenting support: 

0 this LU supports reception of segments on this session. 

1 this LU does not support reception of segments on this session; the BIND 
sender and receiver set the maximum RU sizes, in bytes 10-11 of BIND and 
RSP(BIND), so that segmenting will not occur on the peripheral link for this 
half-session 

bit 1, FM header usage: 

0 FM headers not allowed | 

1 FM headers allowed (only value defined for LU 6.2) 

bit 2, brackets usage and reset state: 

0 brackets not used if neither primary nor secondary will send EB, i.e.» if 
byte 4, bit 7 = 0 and byte 5, bit 7 = 03; brackets are used and bracket state _ 
managers' reset states are INB (1) if either primary or secondary, or both, 
may send EB, i.e., if byte 4, bit 7 = 1 or byte 5, bit 7 = 13 or (2) if FM 
profile 19 is specified (only value defined for LU 6.2) 
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BIND 


1 brackets are used and bracket state managers' reset states are BETB 


bit 3, bracket termination rule selection (reserved if brackets not used, i.e.» if 
byte 6, bit 2 = 0, byte 4, bit 7 = 0, and byte 5, bit 7 = 0; or if FM profile 
is not 19): 
0 Rule 2 (unconditional termination) will be used during this session 
1 Rule 1 (conditional termination) will be used during this session (only val- 
ue defined for LU 6.2) 
bit 4, alternate code set allowed indicator: 
0 alternate code set will not be used 
1 alternate code set may. be used 
bit 5, sequence number availability for syne point resynchronization (reserved if any 
TS profile other than 4 is used): : 
0 sequence numbers not available 
1 sequence numbers available 
Note: Sequence numbers are transaction program sequence numbers from the 
previous activation of the session with the same session name; they are 
associated with the last acknowledged requests and any pending requests to 
commit a unit of work. If no previous activation existed, the numbers are 
0, and this bit 1s set to 0. 
bit 6, BIS sent (reserved for TS profiles other than 4): 
0 BIS not sent 
1 BIS sent 
bit 7, BIND response queue capability: 
0 BIND response cannot be held/queued 
1 BIND sender allows BIND receiver to queue BIND and withhold BIND response 
for an indefinite period 
Note: BIND sender may provide a timer or operator interface to send UNBIND 
if session activation time exceeds BIND sender's limits. BIND queuing is 
terminated by sending UNBIND to the BIND receiver. 
bits 0-1, normal-flow send/receive mode selection: 
00 full-duplex 
01 half-duplex contention 
10 half-duplex flip-flop (only value defined for LU 6.2) 
1l reserved 
bit 2, recovery responsibility (reserved if normal flow send/receive mode is FDX, 
1.e., if byte 7, bits 0-1 = 00): 
0 contention loser responsible for recovery (see byte 7, bit 3 for specifica- 
tion of which half-session is the contention loser) 
1 symmetric responsibility for recovery (only value defined for LU 6.2) 
bit 3, contention winner/loser (reserved if normal flow send/receive mode is FDX, 
i.e., if byte 7, bits 0-1 = 003. or if the normal flow send/receive mode is 
HDX-FF, brackets are not used, FM profile is not 19, and symmetric responsi- 
bility for recovery is used, i.e., if byte 7, bits 0-1 = 10, byte 4, 
bit 7 = 0, byte 5, bit 7 = 0, byte 6, bit 2 = 0, and byte 7, bit 2 = 1): 
0 secondary is contention winner and primary is contention loser 
1 primary is contention winner and secondary is contention loser 
Note: Contention winner is also brackets first speaker if brackets are used. 
bits 4-5, alternate code processing identifier (reserved unless Alternate Code Set 
Allowed indicator [byte 6, bit 4] is 1): 
00 process alternate code FMD RUs as ASCII-7 
01 process alternate code FMD RUs as ASCII-8 (only value defined for LU 6.2) 
Note: When the Alternate Code Processing Identifier indicator is set to the 
value 01, the entire FMD request RU is to be translated using the transforms 
defined by the ANSI X3.26 Hollerith Card Code. 
bit 6, reserved | | 
bit 7, half-duplex flip-flop reset states (reserved unless (1) normal-flow 
: send/receive mode is half-duplex flip-flop (byte 7, bits 0-1 = 10) and (2) 
brackets are not used or bracket state manager's reset state is INB (byte 6, 
bit 2 = 0)): 
0 HDX-FF reset state is RECEIVE for the primary and SEND for the secondary 
(e.g., the secondary sends normal-flow requests first after session acti- 
vation) 
1 HDOX-FF reset state is SEND for the primary and RECEIVE for the secondary 
(e.g., the primary sends normal-flow requests first after session acti- 
vation) (only value defined for LU 6.2) 
TS Usage 
bit 0; staging indicator for secondary TC to primary TC normal flow: 
0 pacing in this direction occurs in one stage 
l pacing in this direction occurs in more than one stage 
Note: The meanings of 0 and 1 are reversed from the staging indicator for 
primary TC to secondary TC. 
bit 1, reserved 
bits 2-7, secondary TC's send window size: 0 means no pacing of requests flowing from 


the secondary 
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10 


ll 


12 


13 


14 


15 


16-22 
23 


24 


bits 0-1, reserved 
bits 2-7, secondary TC's receive window size: a value of 0 causes the boundary func- 
tion to substitute the value set by a system definition pacing parameter (if 
the system definition includes such a parameter) before it sends the BIND RU 
on to the secondary half-session; a value of 0 received at the secondary is 
interpreted to mean no pacing of requests flowing to the secondary 
Maximum RU size sent on the normal flow by the secondary half-session: if bit 0 is 
set to 0 then no maximum is specified and the remaining bits 1-7 are ignored; if bit 0 
is set to 1, the byte is interpreted as X'ab' = a®2%*b (Notice that, by definition, 
a28 and therefore X'‘'ab' is a normalized floating point representation.) See Fig- 
ure E-1 on page E-10 for all possible values. 
Maximum RU size sent on the normal flow by the primary half-session: identical encod- 
ing as described for byte 10 
bit 0, staging indicator for primary TC to secondary TC normal flow: 
1 pacing in this direction occurs in one stage 
0 pacing in this direction occurs in two stages 
Note: The meanings of 0 and 1 are reversed from the staging indicator for 
secondary to primary TC. 
bit 1, reserved 
bits 2-7, primary TC's send window size: a value of 0 causes the value set by a sys- 
tem definition pacing parameter (if the system definition includes such a 
parameter) to be assumed for the session; if this is also 0, it means no 
pacing of requests flowing from the primary (For single-stage pacing in the 
primary-to-secondary direction, this field is redundant with, and will indi- 
cate the same value as, the secondary TC's receive window size—see byte 9; 
bits 2-7, above.) 
bits 0-1, reserved 
bits 2-7, primary TC's receive window size: a value of 0 means no pacing of requests 
- flowing to the primary (For single-stage pacing in the secondary-to-primary 
direction, this field 1s redundant with, and will indicate the same value 
as, the secondary TC's send window size—see byte 8) bits 2-7, above.) 
PS Profile 
bit 0, PS Usage field format: 
0 basic format (only value defined) 
bits 1-7, LU type: 
0000000 LU type 
0000001 LU type 
0000010 LU type 
0000011 LU type 
0000100 LU type 
0000110 LU type 
0000111 LU type 
PS Usage characteristics 
Note: The following format for bytes 15-25 applies only to LU 6.23 for information on. 
PS usage bytes 15-25 for other than LU 6.2 (indicated by byte 14, bits 1-7 = 0000110 
and byte 15 = 00000010), see SNA—Sessions Between Logical Units. 
LU-6 level: 
X'02' Level 2 (i.e., LU 6.2) 
Reserved 
bits 0-2, retired. 
bit 3, conversation-level security support: 
0 Access Security Information field will not be accepted on incoming FMH-5s 
1 Access Security Information field will be accepted on incoming FMH-5s 
bits 4-5, reserved 
bit 6, already-verified function support: 
0 Already Verified indicator will not be accepted on incoming FMH-5s 
| 1 Already Verified indicator will be accepted on incoming FMH-5s 
bit 7, reserved 
bit 0, reserved 
bits 1-2, synchronization level: 
01 confirm is supported 
10 confirm, syne point, and backout are supported 
bit 3, reserved | 
bits 4-5, responsibility for session reinitiation: 
00 operator controlled 
01 primary half-session will reinitiate 
10 secondary half-session will reinitiate 
11 either may reinitiate 
bit 6, parallel session support for LU-LU pair: 
0 not supported 
1 supported 
bit 7, Change Number of Sessions GDS variable flow support (set to 1 1f byte 24, bit 
6 = 1): 
0 not supported 


NA DWN GS 
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26-K 
26 


27 


28-k 


k+l-m 
k+1 


k+2-m 


mti-n. 


m+1 


m+2-n 
m+2 


Note 2: 


BIND 


1 supported 
Reserved 
End of PS Usage Field 
Cryptography Options 


bits 0-1, private cryptography options (reserved for LU 6.2): 
00 no private cryptography supported 
01 private cryptography supported: the session cryptography Key and 
cryptography protocols are privately supplied by the end user 
bits 2-3, session-level cryptography options: 


00 no session-level cryptography supported 

01 session-level selective cryptography supported; all cryptography key man- 
agement is supported by the SSCP and LU; exchange (via +RSP(BIND)) and 
verification (via CRV) of the cryptography session-seed value is sup- 
ported by the LUs for the session; all FMD requests carrying ED are enci- 
phered/deciphered by the TCs 

10 reserved 

11 session-level mandatory cryptography supported; all cryptography key man- 


agement is supported by the SSCP and LU; exchange (via +RSP(BIND)) and 
verification (via CRV) of the cryptography session-seed value 1s sup- 
ported by the LUs for the session; all FMD requests are enci- 


phered/deciphered by TC 
Note: Only values 00 and 11 are defined for LU 6.2. 
bits 4-7, session-level cryptography options field length: 
X'O' no  session-level cryptography speci fied; 
cryptography options fields (bytes 27-k) omitted 
X'9' session-level cryptography specified; additional options follow in next 
nine bytes 
bits 0-1, session cryptography key encipherment method: 
00 session cryptography Key enciphered under SLU master cryptography key 
using a seed value of 0 (only value defined) 
bits 2-4, reserved 
bits 5-7») cryptography cipher method: 
000 block chaining with seed and cipher text feedback, 
Encryption Standard (DES) algorithm (only value defined) 
Session cryptography key enciphered under secondary LU master cryptography key; an 
eight-byte value that, when deciphered, yields the session cryptography key used for 
enciphering and deciphering FMD- requests 
Primary LU Name Field 
Length of primary LU name 
Note: X'00' = no primary LU name present. 
Primary LU name or, if the secondary LU issued the INIT-SELF (or INIT-OTHER), the 
uninterpreted name as carried in that RU (and also in CDINIT for a cross-domain ses- 
sion) 
User Data Field 
Length of user data 
Note: X'00' = no User Data field present; if unstructured user data present, values I 
to 65 are valid. 
User data 
User data key: 
X'00' structured subfields follow (only value defined for LU 6.2) 
Note: Individual structured subfields may be omitted ent vines. 
they _ appear in ascending subfield~-number order. 


following additional 


using the Data 


When present, 


~X'00' first byte of unstructured user data 


For unstructured user data: 

Remainder of unstructured user data 

For structured user data: 

Structured subfields (For detailed definitions, 
Formats" on page E-41.) 

User Request Correlation Field 

Length of user request correlation (URC) field (values 0 to 12 are valid) 
Note: X‘'00' = no URC present. 

URC: LU-defined identifier (present only if carried in INIT from SLU) 
Secondary LU Name Field (present only in negotiable BIND) 

Length of secondary LU name 

Note: X'00' = no secondary LU name present. 

Secondary LU name 


see "User Data Structured Subfield 


The length of the BIND RU cannot exceed 256 bytes, lest a negative response be 


If the last byte of a format 0 request is a length field and that field is 0, that byte 


may be omitted from the BIND request. 
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Exponent 
(b) 


Mantissa (a) 


F 
(15) 


D 
(13) 


E 
(14) 


A 
(10) 


56 
12 


B 
(11) 


Cc 
(12) 


2 288 320 352 384 416 448 480 
5 576 640 704 768 832 896 960 


1024 1152 1280 1408 1536 1664 1792 =1920 


2048 2304 2560 2816 3072 3328 3584 3840 
4096 4608 5120 5632 6144 16656 7168 7680 


8192 9216 10240 11264 12288 13312 14336 15360 


Te cas)_[ sere verse ese teres ison seme eears wre | 
[Fash [esnee eer sree sou Sree sean ste 150 


Note: A value of X'ab' in byte 10 or byte 11 of BIND represents a®2**b. For example, X'CS5' 
represents (in decimal) 12¢2%*5 = 384. 


Figure E-1. RU Sizes Corresponding to Values X'ab' in BIND 
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BINDF 


BINDF; PLU-->SSCP, Norm; FMD NS(s) (BIND FAILURE) 


BINOF is sent, with no-response requested, by the 
PLU to notify the SSCP that the attempt to acti- 


vate the session between the specified LUs has 
failed. 


X'810685'" NS header 

Sense data 

Reason: 

bit 0, reserved 

bit 1, 1 BIND error in reaching SLU 

bit 2, 1 setup reject at PLU 

bit 3, 1 setup reject at SLU 

bits 4-7, reserved 

8-m Session key, as described in the section "Session Keys" on page E-58 
Note: One of the following session keys is used: 

X'07' network address pair: PLU and SLU, respectively 

X'15" network-qualified address pair: PLU and SLU, respectively 


ea ued 
On 


COCINIT$; SSCP-->SSCP, Norm; FMD NS(s) (CROSS-DOMAIN CONTROL INITIATE) 


CDCINIT passes information about the SLU from the 
SSCP(SLU) to the SSCP(PLU) and requests that the 


SSCP(PLU) send CINIT to the PLU. 


0-2 X'81864B" NS header 
3 Format 
bits 0-3, X'O' Format 0: session pair identified by network addresses 
X'l' Format 1: session pair identified by a session key 
bits 4-7, reserved : 


4 Reserved 
5-12 PCID: a unique value used as a session identifier 
13-m Session Pair Identifier 
© For format 0: 
13-14 Network address of PLU 


15-16(=m) Network address of SLU 
® For format 1: 
13-m Session key,» as described in the section "Session Keys” on page E-58 
Note: The following session key is used: 
X'15' network-qualified address pair: PLU and SLU, respectively (only value defined) 
m+1-m+2 Length, in binary, of BIND image 
m+3-n BIND image: bytes l-p of the BIND RU (see BIND format description), i.e., through the 
URC field 
Notes on BIND image: 
° If the last byte of the BIND image is a length field and that length field is 0; 
that byte may be omitted from the BIND image. 
® For SLUs not in the sending SSCP's node, the session cryptography Key 1s enciphered 
under the SLU master cryptography key; for SLUs in the SSCP's node, the sending 
SSCP enciphers the session cryptography key under a dummy SLU master cryptography 
key. 
n+1-n+2 Length, in binary, of LU or non-SNA device characteristics field and format—i.e., 
bytes n#3-p (X'00' = no characteristics/format field. ) 


n+3 LU or non-SNA device characteristics format: 
X'Ol' Format 1: access method unique device characteristics (only value defined) 
n+4-p LU or non-SNA device specifications (See CINIT for the format of this field.) 
p+l Length, in binary, of session cryptography key 
Note: X'00' = no Session Cryptography Key field is present. 
pt2-q Session cryptography key for primary: the session cryptography key, enciphered under 


the cross-domain cryptography key defined for the SSCP(SLU) to SSCP(PLU) direction (a 
different cross-domain cryptography key is defined for the opposite direction) and 
using a seed value of 0 


CDINIT$; SSCP-->SSCP, Norm; FMD NS(s) (CROSS-DOMAIN INITIATE ) 


CDINIT from the SSCP(OLU) requests that the 


SSCP(DLU) assist in initiating an LU-LU_ session 
for the specified (OLU,DLU) pair. 


0-2 X'818641' NS header 
3 Format 
bits 0-3, X'0' Format 0: used when Type = I, I/Q, or Q; bytes 17-18 are reserved and 
no COS fields are specified for Format 03; Format 0 includes bytes 0 
through s 
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CDINIT 


X'1l' Format 1: used when Type = DQ and specifies a subset of the parame- 
ters; Format 1 includes bytes 0 through 18 

X'2’ Format 2: specifies COS fields and an additional OLU status (byte 6; 
bit 5) in addition to the parameters in Format 03 Format 2 includes 
bytes 0 through (s+9) 

X'3' Format 3: used when Type = I, I/Q, or Q; includes bytes 0 through 
(s+9) as in Format 23; control vectors are appended following byte (s+9) 

X'4' Format 4: used when Type = DQ and specifies a subset of the parame- 
ters; Format 4 includes Format 1, plus X'15' Network-Qualified Address 
Pair session key 

bits 4-7, reserved 
Note: Formats 0, 2») and 3 continue (See Format 1 and 4 continuation below) 


4 Type 
bits 0-1, 00 reserved 
O01 initiate only (T) 
10 queue only (Q) 
ll initiate or queue (I/Q) 
bits 2-3, retired 
bit 4, reserved 
bit 5, retired 
bit 6, 0 DLU is PLU 
1 OLU is PLU 
bit 7, retired 
5 Queuing Conditions For DLU (reserved when Type = I) 
bit 0, 0 do not queue if session limit exceeded 
1 queue if session limit exceeded 
bit 1, 0 do not queue if DLU is not currently able to comply with the PLU/SLU spec- 
ification (as given in byte 4, bit 6) 
1 queue if DLU is not currently able to comply with the PLU/SLU specification 
bit 2, reserved 
bit 3, 0 do not queue if no SSCP(DLU)-DLU path 
1 queue if no SSCP(DLU)-DLU path 
bit 4, reserved 
bits 5-6, queuing position/service 
00 put this request on the bottom of the queue (this request is put at the 
bottom of the queue and serviced last) 
01 enqueue this request FIFO 
10 enqueue this request LIFO 
11 reserved 
bit 7, reserved 
Note: Queuing is not done if the DLU is unknown, or if the domain of the DLU is in 
takedown status. 
6 OLU status 
bit 0, reserved 
bit 1, 0 LU is not available 
1 LU is available 
bits 2-3, (used if LU is not available; otherwise, reserved) 
00 LU session limit exceeded 
01 reserved 
10 LU is not currently able to comply with the PLU/SLU speci fication 
ll reserved 
bit 4, 0 existing SSCP to LU path 
l no existing SSCP to LU path (connectivity is lost) 
bit 5, (reserved in format 0) 
0 UNBIND and SESSEND cannot be sent by the LU or by its boundary function (if 
any ) 
1 UNBIND and SESSEND may be sent by the LU or by its boundary function (if 
any ) 
bits 6-7, 01 OLU is PLU 
10 OLU is SLU 


7-14 PCID: a unique value used as a session identifier 
15-16 Network address of OLU (retired for format 3) 
17-18 Reserved 

19 bit 0, INITIATE origin: 


0 ILU is OLU 
I ILU is not OLU 
bits 1-2, reserved 
bit 3, initiator: 
0 network user is the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
20 NOTIFY specification: 
bits 0-1, NOTIFY(X'01') condition 
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21-28 


3l-m 
m+1l—-m+2 
m+3-q 
m+3 


m+4-q 
m+4 


m+5-q 
m+5-q 
qtl-r 
qtl 
qt2 
qt3-r 
rt+l-s 
rtl 
rt2 
r+3-s 
Note: 


stl 


St+2-St9 


Note: 


s+10-t 


End of Format 03 


End of Format 23 


CDINIT 


00 do not send NOTIFY to LUs in session with DLU 
01 reserved 
10 send NOTIFY to all LUs in session with DLU only if the CDINIT request is 
queued 
1l reserved 
bits 2-5, reserved 
bits 6-7, request for notification of resource availability: if a resource required 
for setup of the requested session is temporarily unavailable and subse- 


in the domain of the 
is requested to notify the 


more OLUs 
X'08' 


quently becomes available to one or 
SSCP(OLU), NOTIFY NS(s) key X'O07' or 
SSCP(OLU) of the resource's availability 
00 do not send NOTIFY to the SSCP(OLU) 
01 send a general NOTIFY NS(s) key X'07' or X'08' that does not specify the 
OLU; the SSCP(OLU) will consider the resource to have become available to 
any and all OLUs in its domain 
send NOTIFY NS(s) key X‘'07' 
resource has become available 
send NOTIFY NS(s) key X‘'07' or X'08' with or without specifying the OLU, 
depending on the scope of the resource's availability 

Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image to be used by the SSCP(PLU) to build the 
CINIT request 

Note: For format 3 (cross-network), 
in the network of the OLU. 

Network Name of DLU 

Type: X'F3"' logical unit 

Length, in binary, of symbolic name 
Symbolic name, in EBCDIC characters 
Retired: set to X'‘'0000' 

User Field 

Length, in binary, of user data 
Note: X'00' no user data 1s present. 

User data: user-specific data that is passed to the primary LU on the CINIT request 
User data key 

X'00' structured subfields follow 
-X'00' first byte of unstructured user data 

Note: Individual structured subfields may be omitted entirely. 
they appear tn ascending field number order. 

For unstructured user data 

Remainder of unstructured user data 

For structured user data 

Structured subfields (For detailed definitions, 
Formats'' on page E-41.) 

Network Name of OLU 

Type: X'F3' logical unit 

Length, in binary, of symbolic name 

Symbolic name in EBCDIC characters 

Uninterpreted Name of DLU 

Type: X'F3' logical unit 

Length, in binary, of DLU name 

Note: X'00' = no uninterpreted name is present. 
EBCDIC character string; when present, this name 
INIT-SELF or INIT-OTHER (when ILU=SLU) 
Formats 2 and 3 continue below. 


10 or X'08' specifying the OLU to which the 


il 


this mode name represents the mode name as Known 


When present, 


see "User Data Structured Subfield 


is obtained from the preceding 


COS name initialization indicators: 
bit 0, 0 COS name not received from ILU (see bits 1-2) 
1 COS name received from ILU 

bits 1-2, (reserved if byte stl, bit 0 = 1) 

01 SSCP(DLU) is to initialize COS name (DLU is SLU) 

10 SSCP(OLU) has initialized COS name (OLU is SLU) 
bits 3-7, reserved 
COS name (If byte s+l, bit 0 0 and bits 1-2 01 this field carries unpredictable 
values and is not used): symbolic name of class of service in EBCDIC characters 
Note: For format 3 (cross-network) this COS name represents the COS name as Known In 
the network of the OLU. 
Format 3 continues below: 


One or more control vectors, as described in the section "Control Vectors" 
E-49 
Note: Vector key X'1A' is required for format 3; the other vectors are optional. 


present, they appear in the order specified below. 


on page 


If 
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CDINIT 


X*1A' 
X'14! 
X'19! 
X'19! 

Note: 

4 Type 
bits 0- 
bits 2- 
bit 4) 
bits 5- 

5 

6 
bit 1, 

7-14 PCID: 
Note: 

15-16 

17-18 

Note: 

19-n 
Note: 

CDSESSEND; 

0-2 

3-10 PCID: 
Note: 

11 

l2-n 


NAU Address control vector: this control vector contains the OLU network 
address 


Note: Between gateways, the OLU address is an address recognized in the 
subnetwork on the DLU side of the sending gateway. Within a gateway, the 
OLU address is an address recognized in the network on the OLU side of the 
gateway node, until the SSCP with address alias responsibility is reached. 
This SSCP replaces the received address with an address recognized in the 
network on the DLU side of the gateway node. 

Note: The network ID is identified in the X'19' control vector for the OLU. 


Session Initiation control vector: 

Resource Identifier control vector (for destination LU): 
Resource Identifier control vector (for origin LU): 

End of Format 3; Formats 1 and 4 continue below. 


1, 00 dequeue (DQ) 

3, 00 leave on queue if dequeue retry is unsuccessful 
01 remove from queue if dequeue retry is unsuccessful 
10 do not retry—remove from queue 
1l reserved 

reserved 

6, 00 LU2 is. PLU 
01 LU2 is SLU 
10 reserved 
ll reserved 


bit 7, reserved 

Queuing Status (For LU associated with SSCP sending CDINIT(DQ)) 
bits 0-4, reserved 

bits 5-6, 00 request on bottom of queue 


01 enqueued request FIFO 
10 enqueued request LIFO 
11 reserved 


bit 7, reserved 
LU Status (For LU associated with SSCP sending CDINIT(D@)) 
bit 0, reserved 


0 LU jis unavailable 
1 LU is available 


bits 2-5, reserved 
bits 6-7, 01 LU is PLU 


10 LU is SLU 
a unique value used as a session identifier 
This PCID must be the same as in the original CDINIT request. 


Network address of LUI (retired for format 4) 
Network address of LU2 (retired for format 4) 
End of Format 1; Format 4 continues below. 


Session key, as described in the section "Session Keys" on page E-58 


One of the following session keys 1s used: 


X'15' network-qualified address pair: LUI] and LU2, respectively (only value defined) 


SSCP( PLU )<-->SSCP(SLU), Norm; FMD NS(s) (CROSS-DOMAIN SESSION ENDED) 


CDSESSEND notifies the SSCP that the LU-LU session 


identified by the Session Key has been success ful- 
ly deactivated. 


X'818648' NS header 


a uni que value used as a session identifier 
PCID is used in CDSESSEND only to aid in PIU trace correlation. 


bits 0-3, format: X'0O' (only value defined) 

bits 4-7, reserved 

Session key, as described tn the section "Session Keys" on page E-58 
Note: 
X'06' network name pair: PLU and SLU, respectively 

X'07' network address pair: PLU and SLU; respectively 

X'15' network-qualified address pair: PLU and SLU, respectively 


One of the following session Keys 1s used: 


CDSESSSF3 SSCP(PLU)-->SSCP(SLU), Norm; FMD NS(€s) (CROSS-DOMAIN SESSION SETUP FAILURE ) 


COSESSSF notifies the SSCP(SLU) that the LU-LU 
session initiation identified by the Session Key 


Content field and the specified. PCID for the ini- 
tiation procedure has failed. 
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CDSESSSF 


0-2 X'818645' NS header 
3-10 PCID: a unique value used as a session identifier 
11-14 Sense data 
15 Reason 
bit 0, 1 CINIT error itn reaching PLU 
bit 1, 1 BIND error in reaching SLU 
bit 2, 1 setup reject at PLU 


bit 3, 1 setup reject at SLU 
bits 4-7, reserved 
1l6-n Session Key, as described in the section "Session Keys" on page E-58 
Note: One of the following session Keys is used: 
X'06' network name pair: PLU and SLU, respectively 
X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 


CDSESSST; SSCP(PLU)-->SSCP(SLU), Norm; FMD NS(s) (CROSS-DOMAIN SESSION STARTED) 


CDSESSST notifies the SSCP(SLU) that the LU-LU 
session identified by the Sesston Key Content 


field and the specified PCID for the initiation 
procedure has been successfully activated. 


0-2 X'818646' NS header 

3-10 PCID: a unique value used as a session identifier 

11 Reserved 

l2-n Session key» as described in the section "Session Keys" on page E-58 


Note: One of the following session keys is used: 

X'06' network name pair: PLU and SLU, respectively 

X'07' network address pair: PLU and SLU, respectively 

X'15' network-qualified address pair: PLU and SLU, respectively 


CDSESSTF; SSCP(PLU)-->SSCP(SLU), Norm; FMD NS(s) (CROSS-DOMAIN SESSION TAKEDOWN FAILURE ) 


CDSESSTF notifies the SSCP(SLU) that the termi- 


nation procedure for the LU-LU session identified 
by the Session Key has failed. 


0-2 X'818647' NS header 
3-10 PCID: a unique value used as a session identifier 
Note: PCID is used in CDSESSTF only to aid in PIU trace correlation. 
11-14 Sense data 
15 Reason: 
bit 0, 1 CTERM error in reaching PLU 
bit 1, 1 UNBIND error in reaching SLU 
bit 2, 1 takedown reject at PLU 
bits 3-7, reserved 
16-n Session key, as described tn the section "Session Keys" on page E-58 
Note: One of the following session Keys 1s used: 
X'06' network name pair: PLU and SLU, respectively 
X'07' network address pair: PLU and SLU, respectively 
X'15" network-qualified address pair: PLU and SLU, respectively 


COTERM; SSCP(OLU)-->SSCP(DLU), Norm; FMD NS(s) (CROSS-DOMAIN TERMINATE ) 


CDTERM from the SSCP(OLU) requests that the 
SSCP(DLU) assist in the termination of the 
cross-domain LU-LU session identified by the Ses- 
sion Key and the Type byte of the RU. Each SSCP 
executes that portion of termination processing 
that relates to the LU In its domain. 


0-2 X'818643' NS header 

3 bits 0-3, 0000 Format 0 (only value defined) 
bits 4-7, reserved 

4 Type: 


bits 0-1, 00 request applies to active and pending-active sessions 
01 request applies to active, pending-active, and queued sessions 
10 request applies to queued sessions only 
11 request applies to pending and queued sessions only 
bit 2, reserved if byte 4, bit 7 = 13 otherwise: 
0 forced termination, session to be deactivated immediately and uncondi- 
tionally 
l orderly termination, permitting an end-of-session procedure to be executed 
at the PLU before the session is deactivated 
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COTERM 


14-15 
16-n 


n+l-n+2 


CINIT; 


10-11 
l2-m 


mtl-n 
m+l1 

m+2 
m+3-n 
n+l-n+2 
n+3-r 
n+3 


n+4-r 
n+4 


nt+5-r 


n+5-r 


bit 3, 0 do not send DACTLU to DLU; another session initiation request will be sent 
for DLU 
1 send DACTLU to DLU when appropriate; no further session initiation request 
will be sent (from this sender) for DLU 
bit 4, reserved 
bits 5-6, retired 
bit 7, 0 orderly or forced (see byte 4, bit 2) 
1 cleanup 
PCID: a unique value used as a session identifier 
Note: This PCID 1s used in COTERM only to aid in PIU trace correlation. 
Reason: 
bit 0, 0 network user 
1 network manager 
bit 1, 0 normal 
1 abnormal 
bits 2-7, reserved 
Reserved 
Session key, as described in the section ''Session Keys" on page E-58 
Note: One of the following session keys is used: 
X'05' PCID: generated by the SSCP(ILU) 
X'06' network name pair: OLU and DLU, respectively 
X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 
Retired 


SSCP-->PLU, Norm; FMD NS(s) (CONTROL INITIATE ) 


CINIT requests the PLU to attempt to activate, via 
a BIND request, a session with the specified SLU. 


X'810601' NS header 
Format 
bits 0-3, 0000 Format 0 (only value defined) 
Note: CINIT format 0 may carry control vectors at the end of the basic 
RU. 
bits 4-7, reserved 
bit 0, INITIATE origin: 
0 ILU is OLU 
1 ILU is not OLU 
bit 1, reserved » 
bit 2, 0 SLU is OLU 
1 PLU is OLU 
bit 3, initiator: 
0 network user is the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
Session Key, as described in the section "Session Keys" on page E-58 
Note: The following session key 1s used: 
X'07' network address pair: PLU and SLU, respectively 
Note: If control vector X'15' 1s supported by the LU, then bytes 5-9 are 
reserved; otherwise, these bytes contain session Key X'07'. 
Length, in binary, of BIND Image field 
BIND image: bytes I-p of the BIND RU, 1.e., through the URC field (see BIND format 
description) 
Note: The URC Length field is included, even if it 1s set to 0. 
Name of SLU 
Type: X'F3' logical unit 
Length, in binary», of symbolic name 
Symbolic name, tn EBCDIC characters 
Retired: 
User Field (from INITIATE RU) 
Length, in binary, of user data 
Note: X'00' = no user data 1s present. 
User data: user-specific data 
User data key: 
X'00' structured subfields follow 
-X'00' first byte of unstructured user data 
Note: Individual structured subfields may be omitted entirely. When present; 
they appear in ascending field number order. 


® For unstructured user data 


Remainder of unstructured user data 


® For structured user data 


Structured subfields (For detailed definitions, see “User Data Structured Subfield 
Formats" on page E-41.) 
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rtl-s 
r+l-r+2 


r+4 


r+5 


r+6 


r+7 


r+8 
r+9 


r+10 


CINIT 


LU or Non-SNA Device Specifications 

Length, in binary, of characteristics field, including both format and characteristics 
fields—i.e., bytes r+3-s 

Note: X'0000" = no Format and no Characteristics fields are present. 

Characteristics field 

Characteristics format: 

X'O1' device characteristics (only value defined) 

LU or Non-SNA Device Characteristics 

Format X'Ol': (This format represents an access-method-unique LU/device character- 
istics definition. For more specific information refer to access method implementa- 
tion documentation. ) 

Scheduling information: 

X'80' input device 

X'GO' output device 

X'20' conversational mode 

X'10' reserved 

x'08' start print sensitive 

X'04' reserved 

X'02' additional information provided (always on) 

X'O1' specific poll=on general poll=off 

Device type: 

X'00' undefined device type 


X'04' 2741 
X'08' WITTY 
X'10' L15A 
X'20' TNX (33-35) 
X'30' 83B3 
X'40' 2740 
X'80' 1050 
X'90' 2780 
KX'19' 3277 
X'IA' 3284 
X'1B' 3286/3288 
X'1C' 3275 
X'91' 3780 


X'6D' SNA logical unit 
Model information: 
X'00' Model 1 
X'O1' Model 2 
Feature information: 
bits 0-1, 00 SDLC 
01 start/stop 
10 BSC 
ll reserved 
bits 2-7, X'20' XMIT interrupt feature 
X'10' SWITCHED LINE = ON; LEASED LINE = OFF 
X'08' attention 
X'04' checking 
X'02' station control 
X'O1' selector pen 
Physical device address 
Miscellaneous flags: 
X'80' SNA compatible application program interface (always on) 
X'S40' non-SNA application program interface (always off) 
X'20' buffered 
X'10' continue mode 
X'08' contention mode 
X'04' inhibit mode (text timeout) 
X'02' end-to-end control 
X'Ol' 3270 extended data stream requiring BSC transparency 
Device data stream compatibility characteristics: (This field is used in conjunction 
with the Device Type field, r+5, when that field is set to X'6D': SNA logical unit; 
otherwise, it 1s reserved. ): 
X'00' no data stream characteristics defined here 


X'04' 2741 
X'08' WITTY 
X'10' LISA 
X'20' THX (33-35) 
X'30' 83B3 
X'40' 2740 
X'80' 1050 
X'90' 2780 
X'19' 3277 
X'1A' 3284 
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CINIT 


E-18 


X'1B' 3286/3288 


X'1C' 3275 

X'91* 3780 

X'AO'-X'FF' available for installation-defined use 
r+ll1 Reserved 
rtl2-r+16 Screen size (see the PS Usage field in the BIND RU for format) 
r+l7-s Work Area (This field is optional—if not present, s = r+16.): 
r+17 Work area format 


X'00' unformatted 
X'O1' TCAM format 
r+18-s Work area excluding format 


s+l Length of Session Cryptography Key field 
Note; X'00' = no Session Cryptography Key field present. 


st2-t Session Cryptography Key field: 
cryptography Key 
Note: End of base RU 


session cryptography key enciphered under PLU master 


t+l-u Control vector, as described in the section "Control Vectors" on page E-49 
Note: The following vector Keys are used in CINIT: 
X'0D' Mode/Class of Service/Virtual Route List 
X'15" network-qualified address pair: PLU and SLU, respectively 


CLEANUP; SSCP-->PLU|SLU, Norm; FMD NS(s) (CLEAN UP SESSION) 


CLEANUP is sent by the SSCP to an LU (in a subarea 
node or BF for peripheral LU) requesting that the 
LU or BF attempt to deactivate the session for the | 
specified (PLU,SLU) network address pair. 


0-2 X'810629' NS header 

3 bits 0-3, 0000 Format 0 (only value defined) 
bits 4-7, reserved 

4 Reserved 

5 Reason: 


bit 0, 0 network user 

1 network manager 
bit 1, 0 normal 

1 abnormal 
bits 2-7, reserved 


6-n Session key, as described in the section "Session Keys" on page E-58 
Note: One of the following session Keys 1s used: 


X'06' uninterpreted name pair: 


PLU and SLU, respectively 


X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 


CONTACTED; PU_T4|5-->SSCP, PU-->PUCP, Norm; FMD NS(c) (CONTACTED) 


CONTACTED is issued by the PU to indicate to the 


SSCP the completion of the DLC contact procedure. 
A status parameter conveyed by this request 
informs SSCP configuration services whether or not 


the contact procedure was successful; if not suc- 
cessful, the status indicates whether an adjacent 
node load is required or whether an error occurred 


on the contact procedure. 


X'010280' NS header 


0-2 
3-4 Element address of adjacent link station in the node being contacted, if ENA is sup- 


ported; otherwise, its network address 
5 Status of adjacent link station or node associated with adjacent link station: 


X'OQ1' loaded (no field follows) 


X'02' load required (no field follows) 

X'03' error on CONTACT (no field follows) 

X'04' loaded (additional field, bytes 6-p, follows) 

X'05' exchanged parameters in XID Format 2 I-field not compatible (additional field, 


bytes 6-p, follows) 


X'07' no routing capability to adjacent node (additional field, bytes 6-p, follows) 

X'08' incompatible parameters in XID Format 2 I-field for addition of link station to 
currently active TG (additional field, bytes 6-p, follows) 

X'09' loaded, in another subnetwork (bytes 19-26 are added after byte 18 of X'04' sta- 


tus ) 


Note: End of RU for status bytes X'01', X'02', and X'03'; RU continues for status bytes X'04', 


X05", X'07', X'08', and X'09' 


Systems Network Architecture Format and Protocol Reference Manual: SNA Network Interconnection 


CONTACTED 
6-p Additional fields for status bytes X'04', X'05', X'07', X'08', and X'09' 
® For status bytes X'04' and X'09' 
6 Resolved TG number 
7-10 Adjacent node subarea address (right-justified with leading 0's) 
11-18(=p) IPL load module ID received from the adjacent node: an eight-character EBCDIC symbolic 
name of the IPL load module currently operating in the adjacent node 
Note: X'40...40' = no information conveyed. 


Note: End of RU for status byte X'04'3; RU continues for status byte X'09' 


19-26(=p) Network ID 
Note: End of RU for 


of the subnetwork that contains the contacted station 
status byte X'09' 


® For status bytes X'05', X'07', and X'08' 


6 Length, in binary, of XID Format 2 I-field received 
7-n XID Format 2 I-field received (See SNA Reference Summary for format details.) 


n+l Length, in binary, of XID Format 2 I-field sent 
n+2-p XID Format 2 I-field sent (See SNA Reference Summary for format details.) 
Note: End of RU for status bytes X'05', X'07', and X'08' 
CTERM; SSCP-->PLU, Norm; FMD NS(€s) CCONTROL TERMINATE ) 
CTERM requests that the PLU attempt to deactivate 
a session identified by the specified (PLU,SLU) 
network address pair. 
0-2 X'810602' NS header 
3 bits 0-3, 0000 Format 0 (only value defined) 
bits 4-7, reserved 
4 Type: 
bits 0-1, reserved 
bits 2-3, 00 reserved 
01 orderly 
10 forced 
11 reserved 
bits 4-7, reserved 
5 Reason: 
bit 0, 0 network user 
l network manager 
bit 1, 0 normal 
1 abnormal 
bits 2-7, reserved 
6-7 Reserved 
8-m Session key, as described in the section "Session Keys" on page E-58 
Note: One of the following session keys 1s used: 
X'07' network address pair: PLU and SLU, respectively 
X'15' network-qualified address pair: PLU and SLU, respectively 
m+ l-m+2 Retired 
DACTCDRM; SSCP-->SSCP, Exp; SC (DEACTIVATE CROSS-DOMAIN RESOURCE MANAGER ) 
DACTCDRM is’ sent to deactivate an SSCP-SSCP ses- 
sion. 
0 X'15' request code 
l bits 0-3, format: X'0' (only value defined) 
bits 4-7, type deactivation requested: 
X'1' normal end of session | 
X'2' invalid activation parameter, sent by the primary half-session to deac- 
tivate the session and to indicate to the secondary that the response 
to ACTCDRM contained an invalid parameter 
X'3' session outage notification (SON) 
© End of Type 13; Type 2 Continues 
2-5 Reason code (included only if type deactivation requested 1s invalid activation param- 


eter, 1.@., byte 1, bits 4-7 = X'2'): 
the error 
® End of Type 2; Type 3 Continues 
2 Cause of session outage notification: 
X'07' virtual route inoperative: the virtual route being used by the SSCP-SSCP ses- 
sion has become inoperative, thus forcing the deactivation of the SSCP-SSCP ses- 
sion 
virtual route deactivated: the identified SSCP-SSCP session is being deacti- 
vated because of a forced deactivation of the virtual route being used by the 
session 


sense data (see Appendix G) corresponding to 


X'0B' 
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DACTCDRM 


E-20 


3 


X'0C' SSCP failure—unrecoverable: the identified SSCP-SSCP session had to be deacti- 
vated because of an abnormal termination of one of the SSCPs of the session; 
recovery from the failure was not possible 

X'OD' session override: the subject session has to be deactivated because of a more 
recent session activation request for the same session over a different virtual 
route 

X'OE' SSCP failure—recoverable: the identified SSCP-SSCP session had to be deacti- 
vated because of an abnormal termination of one of the SSCPs of the session; 
recovery from the failure may be possible 

X'OF' cleanup: the SSCP is resetting its half-session before it receives the response 
from the partner SSCP receiving the DACTCDRM 

X'10° SSCP contention: two SSCPs have sent each other an ACTCDRM request over differ- 
ent virtual routes; the SSCP receiving the ACTCDRM from the SSCP with the great- 
er SSCP ID sends DACTCDRM, with this SON code, to the other SSCP over the same 
virtual route on which the contention-losing ACTCDRM was sent 

X'11' gateway node cleanup: a gateway node is cleaning up the session because the 
gateway SSCP session partner has forced deactivation of the session (via NOTIFY) 
Note: In this case, the receiving SSCP does not send NOTIFY to the gateway 
node. 

Reserved 


DACTPU; SSCPIPUCP-->PU, PU-->SSCP, Exp; SC (DEACTIVATE PHYSICAL UNIT) 


DACTPU is sent to deactivate the session between | 
the SSCP and the PU. | 


X'12' request code 

Type deactivation requested: 

X'01' final use, physical connection may be broken 

X'02' not final use, physical connection should not be broken 

X'03' session outage notification (SON) 

Cause (not present if byte 1 # X'03'): 

X'07' virtual route inoperative: the virtual route for the SSCP-PU session has become 
inoperative, thus forcing the deactivation of the SSCP-PU session 

X'08' route extension inoperative: the route extension serving the SSCP-PU session 
has become inoperative, thus forcing the deactivation of the SSCP-PU session 

X'09' hierarchical reset: the identified session is being deactivated because of a 
+RSPCACTPU, Cold) 

X'0B' virtual route deactivated: the identified SSCP-PU session is being deactivated 
because of a forced deactivation of the virtual route being used by the session 

X'0C' SSCP or PU failure—unrecoverable: the identified SSCP-PU session had to be 
deactivated because of an abnormal termination of the SSCP or PU of the session; 

recovery from the fatlure was not possible 

X'OD' session override: the SSCP-PU session has to be deactivated because of a more 
recent session activation request for the SSCP to subarea PU session over a dif- 
ferent virtual route 

X'OE' SSCP or PU failure—recoverable: the identified SSCP-PU session had to be deac- 
tivated because of an abnormal termination of the SSCP or PU of the session; 
recovery from the failure may be possible 

X'OF' cleanup: the SSCP is resetting its half-session before receiving the response 
from the PU that is being deactivated. 


DSRLST$ SSCP-->SSCP, Norm; FMD NS(s) (DIRECT SEARCH LIST) 


DSRLST identifies a control list type and speci- 
fies a list search argument to be used at the 


receiving SSCP. 


X'818627' NS header 

Search argument type: 

X'O1' network name of an LU for which an LU Status control list (type X'01') is to be 
returned 

X'02' Resource Identifier control vector identifying an LU in another network for 
which an LU Status control list (type X'01') is to be returned 

X'03" Resource Identifier control vector identifying an LU in another network for 
which an SSCP Capability control list (type X'03') is to be returned 

For search argument X'OL1' 

Network Name of LU 

Type: X'F3' logical unit 

Length, in binary, of symbolic name 

Symbolic name in EBCDIC characters 

For search argument X'02' 

Resource Identifier (X'19') control vector (This control vector identifies the LU as 

Known by the originating SSCP. ) 
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DSRLST 


® For search argument X'03' 


Resource Identifier (X'19') control vector (This control vector identifies the LU as 
Known to the originating SSCP—the SSCP name, if Known, 1s the name of the SSCP in 
whose domain the target LU is defined, not the name of the SSCP on the target side of 
this gateway. ) 


ER-TESTED; PU_T4|5-->SSCP, Norm; FMD NS(ma) (EXPLICIT ROUTE TESTED) 


47 
Note: 


48-51 


52 


53-60 


61-62 


ER-TESTED is sent by a subarea node to one or more 


SSCPs to provide the status of an ER as determined 
by explicit route test procedures. 


X'410386' NS header 

Format: 

X'l' Format 1 

X'2' Format 23; same as Format 1, except that it tncludes bytes 48-n 

Type: 

X'00' the corresponding NC-ER-TEST reached its destination subarea 

X'02' ER not reversible since there is no reverse ERN defined 

X'03' Retired 

X'04' ER length exceeded that specified in the NC-ER-TEST request 

X'05' ER requires a TG that 1s not active 

X'06' ER is not defined in the NC-ER-TEST-REPLY originating node 

X'07' Retired 

Explicit route length, in terms of the number of transmission groups in the explicit 
route, as accumulated in NC-ER-TEST 

Maximum ER length, as specified in the NC-ER-TEST request 

Subarea address of the destination PU of the corresponding NC-ER-TEST 
Reserved 

bits 0-3, reserved 

bits 4-7, ERN of the ER tested 

Subarea address of the originating PU of the corresponding NC-ER-TEST 
Reverse ERN mask: A bit is on if the corresponding ERN can be used to route from the 
NC-ER-TEST-REPLY originating subarea to the NC-ER-TEST originating subarea (Bit 0 cor- 
responds to ERN 0, bit 1 to ERN 1, and so forth.) 

Maximum PIU length allowed on the reverse ERN specified in byte 17-18: 

X'00' no restriction (only value defined) 

Maximum PIU size accumulated by the corresponding NC-ER-TEST: 

X'00' no restriction (only value defined) 

Network address of the SSCP originating the test request 

Request Correlation field, as specified in the corresponding ROUTE-TEST 
Subarea address of the PU that originated the corresponding NC-ER-TEST-REPLY 
Subarea address depending on the Type field (byte 4) as follows: 


Type Contents of this field 

X'00' reserved 

X'02' subarea on the ER prior to that with no reverse ERN defined 

X'03' reserved 

X'04' subarea on the ER preceding the subarea where the explicit route length 


(byte 5 of NC-ER-TEST) is incremented to a value one more than the maximum 
ER length limit (byte 6) 


X'05' subarea on the other end of the TG that is not active 

X'06' subarea on the ER from which the PU (that does not have the ER defined) 
| received the corresponding NC-ER-TEST 

X'07' reserved 


TGN of the TG between the subareas specified in bytes 39-42 and 43-463 reserved if 
Type is X'00' 


End of Format 13; Format 2 continues below 


Subarea address of the adjacent node through which the tested explicit route flows 
from the node receiving ROUTE-TEST 

Note: Bytes 48-51 are reserved if this request is built by nodes other than the ori- 
ginal receiver of ROUTE-TEST. 

Transmission group number of the TG (to the node identified in bytes 48-51) over which 
the tested explicit route flows from the node receiving ROUTE-TEST 

Note: Byte 52 is reserved if this request is built by nodes other than the original 
receiver of ROUTE-TEST 

Network ID of subnetwork containing the ER 

Note: This network ID defines the subnetwork in which the above addresses are valid. 
Bit mask of VRs that use the ER specified by bytes 7-16 (bit nm corresponds to VRN n) 
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ER-TESTED 


63-n 


Note: Bytes 61-62 are reserved if this request is built by nodes other than the ori- 

ginal receiver of ROUTE-TEST. 

One or more control vectors, as described in the section "Control Vectors" on page 

E-49 . 

Note: The following vector key may be used in ER-TESTED format 2: 

X'LF' ER Configuration control vector one X'IF' control vector is included for each 
node along the route that supports this vector in NC-ER-TEST-REPLY. ) 


INIT-OTHER; ILU-->SSCP, Norm; FMD NS(s) CINITIATE-OTHER ) 


INIT-OTHER from the ILU requests the initiation of 
a session between the two LUs named in the RU. 
The requester may be a third-party LU or one of 


the two named LUs. This RU is not used by LU 6.2, 
although it can be used by a third-party LU for LU 
6.2. 


X'810680' NS header 
Format: 
bits 0-3, 0001 Format 1 
0010 Format 2: specifies the COS name field in addition to the parameters 
in Format 1 
bits 4-7, reserved 
Type: 
bits 0-1, 00 dequeue (DQ) a previously enqueued initiate request (See bits 2-3 for 
further specification of dequeue actions. ) 
Ol initiate only (I): do not enqueue 
10 enqueue only (Q) (See bytes 5-6 for further specification of queuing con- 
ditions. ) 
ll initiate/enqueue (I/Q): enqueue the request if it cannot be satisfied 
imnediately 
bits 2-3, (used for DQ; otherwise, reserved) 
00 leave on queue if dequeuing attempt is unsuccessful 
01 remove from queue if dequeuing attempt is unsuccessful 
10 remove from queue; do not attempt initiation 
1l reserved 
bit 4, reserved 
bits 5-6, PLU/SLU specification: 
00 LUI is PLU 
01 LU2 ts PLU 
bit 7, reserved 
Queuing conditions for LUI (reserved when Type = DQ) 
bit 0, 0 do not enqueue if session limit will be exceeded 
1 enqueue if session limit will be exceeded 
bit 1, 0 do not enqueue if the LU ts not currently able to nai with the PLU/SLU 
specification (as given in byte 4, bits 5-6) 
1 enqueue even though the LU might not be currently able to comply with the 
PLU/SLU specification 
bit 2, reserved 
bit 3, 0 do not enqueue if there are no SSCP-LU paths 
1 enqueue if there are no SSCP-LU paths 
bit 4, reserved 
bits 5-6, queuing position/service 
00 enqueue this request at the bottom of the queue (the request 1s put at 
the bottom of the queue and serviced last) 
01 enqueue this request FIFO 
10 enqueue this request LIFO 
ll reserved 
bit 7, reserved 
Note: Enqueueing is not performed if the DLU is unknown, or if the domain of either 
LU is In takedown status. 
Queuing conditions for LU2 (reserved when Type = DQ): 
bit 0, 0 do not enqueue if session limit will be exceeded 
1 enqueue if session limit will be exceeded 
bit 1, 0 do not enqueue if the LU is not currently able to comply with the PLU/SLU 
specification (as given in byte 4, bits 5-6) 
1 enqueue even though the LU might not be currently able to comply: with the 
PLU/SLU specification 
bit 2, reserved 
bit 3, 0 do not enqueue if there are no SSCP-LU paths 
1 enqueue if there are no SSCP-LU paths 
bit 4), reserved 
bits 5-6, queuing position/service 
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n+5-r 


n+5-r 


r+il-s 


r+] 


r+2-s 


s+l-s+8 


Note: 


End of Format 13 


INIT-OTHER © 


enqueue this request at the bottom of the queue (the request is put at 
the bottom of the queue and serviced last) 
enqueue this request FIFO 
enqueue this request LIFO 
reserved 
bit 7, reserved 
Note: Enqueuetng is not performed if the DLU is unknown, or if the domain of either 
LU is in takedown status. 
bits 0-2, reserved 
bit 3, initiator (reserved when Type = DQ): 
0 network user is the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
NOTIFY specifications: 


bits 0-3, NOTIFY(X'O1') conditions (reserved when Type = 0Q) 
bits 0-1, 00 do not send NOTIFY to LUs in session with LUI 
01 reserved 
10 send NOTIFY to all LUs in session with LUI only if the request 1s queued 
ll reserved 
bits 2-3, 00 do not send NOTIFY to LUs in session with LU2 
01 reserved 
10 send NOTIFY to all LUs in session with LU2 only if the request is 
enqueued 
11 reserved 
bit 4, reserved 
bit 5, NOTIFY(X'03') conditions 
0 do not send NOTIFY to the ILU when the requested session is set up 
1 send NOTIFY to the ILU when the requested session is set up 
bit 6) reserved 
bit 7, request for notification of resource availability: if a resource required for 


setup of the requested session is temporarily unavailable and subsequently 

becomes available, NOTIFY NS(s) key X'07' is Sere es to notify the initiator 

of the resource's availability 

0 do not send NOTIFY to the initiator 

1 send NOTIFY NS(s)} Key X'07' to the initiator 
Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image that will be used by the SSCP(PLU) to build 
the CINIT request (reserved when Type = DQ) 
Uninterpreted name of LUI 
Type: X'F3' logical unit 
Length, in binary, of LUI 
EBCDIC character string 
Uninterpreted name of LU2 
Type: X'F3' logical unit 
Length, in binary, of LU2 name 
EBCDIC character string 
Retired 
User Field (reserved when Type 
Length, in binary, of user data 
Note: X'00' = no user data 1s present. 
User data 
User data key 
X'00' structured subfields follow 


name 


= DQ) 


~X'00' first byte of unstructured user data 


Note: Individual structured subfields may be omitted entirely. When present, 
they appear in ascending field number order. 

For unstructured user data 

Remainder of unstructured user data 

For structured user data 

Structured subfields (For detailed definitions, 


Formats" on page E-41.) 


see "User Data Structured Subfield 


User Request Correlation (URC) field (When type = DQ, the URC must be the same as on 


the original INIT-OTHER request. ) 

Length, in binary», of URC 

X'O0O' = no URC. 

URC: LU-defined identifier; this value can be returned by the SSCP in a subsequent 
NOTIFY to correlate a given session to the initiating request 

Format 2 Continues 

COS name: symbolic name of class of service in EBCDIC characters (A value of eight 
space (X'40') characters may be specified; in this case, the COS name is derived from 
the mode name table, using the mode name received in byes 9-16.) 
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INIT-OTHER-CD 


E-24 


INIT-OTHER-CD; SSCP-->SSCP, Norm; FMD NS(s) CINITIATE-OTHER CROSS-DOMAIN) 


0-2 X'818640' 
3 Format: 
bits 0-3, 


bits 4-7, 
4 Type: 


bits O-l, 


bits on-3, 


INIT-OTHER-CD from the SSCPCILU) requests that a 
session be initiated between the two LUs named in 
the RU. The INIT-OTHER-CD request simply trans- 
ports an INIT-OTHER from the SSCP(ILU) (a third 
party SSCP in this case) to the SSCP(OLU). 


NS header 


0000 Format 0 

0010 Format 2 specifies COS name field in addition to the parameters in For- 
mat 0 

0011 Format 3 is the cross-network version of format 2 and includes a 
Resource Identifier control vector for rerouting in addition to the 
parameters in Format 2 

reserved 


00 dequeue (DQ) a previously enqueued initiate request. (See bits 2-3 for 
further specification of dequeue actions. ) | 

01 initiate only (I): do not enqueue 

10 enqueue only (Q): (See bytes 5-6 for further specification of queuing 
conditions. ) 

1l initiate/enqueuve (I/Q): enqueue the request if it cannot be satisfied 
immediately 

(used for DQ; otherwise, reserved) 

00 leave on queue if decieu'ng attempt is unsuccessful 

01 remove from queue if dequeuing attempt is unsuccessful 

10 remove from queue, do not attempt initiation 

ll reserved 


bit 4, reserved 


bits 5-6, 


PLU/SLU specification: 
00 LUL is PLU 
01 LU2 is PLU 


bit 7, reserved 
5 Queuing conditions for LUL (When Type = 0@, bits 0-7 are reserved. ): 


bit 0, 0 
1 
bit 1, 0 


l 


do not enqueue if session limit will be exceeded 

enqueue if session limit will be exceeded 

do not enqueue if the LU is not currently able to comply with the PLU/SLU 
specification (as given in byte 4, bits 5-6) 

enqueue if the LU is not currently able to comply with the PLU/SLU speci fi- 
cation 


bit 2, reserved 


bit 3, 0 
i 


do not enqueue if there are no SSCP-LU paths 
enqueue if there are no SSCP-LU paths . 


bit 4, reserved 


bits 5-6, 


00 enqueue this request at the bottom of the queue (the request is put at 
the bottom of the queue and serviced last) 

01 enqueue this request FIFO 

10 enqueue this request LIFO 

ll reserved 


bit 7, reserved 
Note: Enqueuing is not performed if the DLU is unknown, or if the domain of either LU 
is in takedown status. 

6 Queuing conditions for LU2 (Nhen Type = DQ, bits 0-7 are reserved. ): 


bit 0, 0 
ot 
bit 1, 0 


l 


do not enqueue 1f session limit will be exceeded 

enqueue if session limit will be exceeded 

do not enqueue if the LU is not currently able to comply with the PLU/SLU 
specification (as given in byte 4, bits 5-6) 

enqueue even though the LU might not be currently able to comply with the 
PLU/SLU specification 


bit 2, reserved 


bit 3, 0 
1 


do not enqueue if there are no SSCP-LU paths 
enqueue even if there are no SSCP-LU paths 


bit 4, reserved 


bits 5-6, 


queuing position/service: 

00 enqueue this request at the bottom of the queue (the request at the bot- 
tom of the queue and is serviced last) 

01 enqueue this request FIFO 

10 enqueue this request LIFO 

11 reserved 


bit 7, reserved 
Note: Enqueuing is not performed if the DLU is unknown, or if the domain of either LU 
is in takedown status. 
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7-14 PCID: a unique value used as a session identifier 
Note: When Type = DQ, the PCID 1s the same as in the original INIT-OTHER-CD request. 
15 bits 0-2, reserved 
bit 3, initiator (reserved when Type = DQ): 
0 network user 1s the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
16 NOTIFY specifications: 
bits 0-3, NOTIFY(X'01') conditions (reserved when type = DQ) 
bits 0-1, 00 do not send NOTIFY to LUs in session with LUI 
01 reserved . 
10 send NOTIFY to all LUs tn session with LUI only if the request is 
enqueued 
1l reserved 
bits 2-3, 00 do not send NOTIFY to LUs in session with LU2 
01 reserved 
10 send NOTIFY to all LUs in session with LU2 only if the request is 
enqueued. 
11 reserved 
bit 4, reserved 
bit 5, NOTIFY(X'03') condition 
0 do not send NOTIFY to the SSCP(ILU) when the requested session is set up 
1 send NOTIFY to the SSCP(ILU) when the requested session ts set up 
bits 6-7, reserved 
17-24 Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image that will be used by the SSCP(PLU) to build 
the CINIT request (reserved when type = DQ) 


25-m Network Name of LUI 
25 Type: X'F3' logical unit 
26 Length, in binary, of symbolic name 
27-m Symbolic name, in EBCDIC characters 
m+1l-n Network Name of LU2 
m+] Type: X'F3' logical unit 
m+2 Length, in binary, of symbolic name 
m+3-n Symbolic name, in EBCDIC characters 
ntl-n+2 Retired: set to X'0000' 
n+3-r User Field (reserved when type = DQ) 
n+3 Length, in binary, of user data 

Note: X‘'00' = no user data is present. 
n+4-r User data: user-specific data that is passed to the primary LU on the CINIT request 
n+4 User data key 


X'00' structured subfields follow 
“X'00° first byte of unstructured user data 
Note: Individual structured subfields may be omitted entirely. When present, 
they appear in ascending field number order. 
® For unstructured user data 


n+5-r Remainder of unstructured user data 
®* For structured user data 
n+5-r Structured subfields (For detailed definitions, see "User Data Structured Subfield 


Formats" on page E-41.) 
Note: With the exception of the NS header and PCID, all the fields in the 
INIT-OTHER-CD RU are derived from its corresponding INIT-OTHER RU. 

Note: End of Format 03; Formats 2 and 3 continue below. 


r+l COS name field initialization indicator: 

bit 0, 0 ILU did not specify COS name 
1 ILU did specify COS name 

bits 1-7, reserved 

r+2-r+9 COS name (reserved if byte r+l, bit 0 = 0): symbolic name of class of service in 
EBCDIC characters (A value of eight space (X'40') characters may be specified; in this 
case, the COS name is derived from the mode name table using the mode name received in 
bytes 17-24.) 

Note: End of Format 23; Format 3 continues below. 


r+l0-r+17 Network ID of subnetwork in which the ILU 1s located and the names of LUI] (bytes 27-m) 
and LU2 (bytes m+3-n) are Known 

r+18-r+25 Network ID of subnetwork in which the following COS name 1s defined 

r+26-r+33 COS name as known in the above network 
Note: Bytes r+26-r+33 contain the class of service name that results from translation 
of the COS name in bytes r+2-r+9 to the corresponding COS name in the network indi- 
cated in bytes r+l8-r+25. 

r+34-r+41 Mode Name as Known in the network of the target LU 
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INIT-OTHER-CD 


E-26 


r+42-s 


INIT-SELF $ 


m+l-m+2 
m+3-n 
mt3 


m+4-n 
m+4 


Control vectors, as described in the section "Control Vectors" on page E-49 

Note: The following control vector keys are used: 

X'19' Resource Identifier control vector for LUI 

X'19' Resource Identifier control vector for LU2 

Note: One of the LUs is selected by the SSCP(ILU) as the target LU. The X'19' vector 
that represents the selected LU has the "target resource indicator" bit set to l. 


ILU-->SSCP, Norm; FMD NS(s) CINITIATE-SELF ) 


INIT-SELF from the ILU requests that the SSCP 
authorize and assist In the initiation of a ses~ 
sion between the LU sending the request (that is, 


the ILU, which also becomes the OLU) and the LU 
named in the request (the DLU). This RU is mot 
used for LU 6.23; refer to INIT-SELF Format 1. 


X'010681' NS header 
bits 0-3, format: 
0000 Format 0: specifies a subset of the parameters shown in Format 1 of 
INIT-SELF (described separately, because the NS header differs in the 
first byte), with the receiver supplying default values 
bit 4, reserved 
bits 5-6, 00 DLU is PLU 
O01 DLU is SLU 
bit 7, 0 initiate only (I): do not enqueue. 
l initiate/enqueue (I/Q): enqueue the request if it cannot be satisfied tmme- 
diately 
Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image that will be used by the SSCP(PLU) to build 
the CINIT request 
Uninterpreted Name of DLU 
Type: X'F3' logical unit 
Length, in binary, of DLU name 
EBCDIC character string 


Retired 

User Field 

Length, in binary, of user data 

Note: X'00' = no user data is present. 


User data: user-specific data that is passed to the primary LU on the CINIT request 
User data Key 
X'00' structured subfields follow 


-X'00' first byte of unstructured user data 


e@ 
m+5-n 

e 
m+5-n 


Note: Individual structured subfields may be omitted entirely. When present, 
they appear in ascending field number order. 

For unstructured user data 

Remainder of unstructured user data 

For structured user data 

Structured subfields (For detailed definitions, see "User Data Structured Subfield 

Formats" on page E-41.) 


Note: The following default values are supplied by the SSCP(ILU) receiving the Format 0 


INIT-SELF 


request: 


¢ Queuing conditions (Cif queuing is specified): 


-  Enqueue if session limit exceeded. 
—- Enqueue this request FIFO. 


° Initiate origin: network user is the initiator. 


° NOTIFY: do not notify 


INIT-SELF 3 


ILU-->SSCP, Norm; FMD NS(s) (INITIATE-SELF ) 


INIT-SELF from the ILU requests that the SSCP 
authorize and assist in the tnititation of a ses- 


sion between the LU sending the request (that is, 
the ILU, which also becomes the OLU) and the LU 
named in the request (the DLU). 


X'810681' NS header 
bits 0-3, format: 
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n+l-n+2 
n+3-r 
n+3 


n+4-r 


INIT-SELF Format 1 and 2 


0001 Format 1: specifies queuing, initiate origin, NOTIFY, and URC in addi- 
tion to the parameters in Format 0 (only value defined for LU 6.2) 
0010 Format 2: specifies the COS name field in addition to the parameters 
in Format 1 
bits 4-7, reserved 
Type: 
bits 0-1, 00 dequeue (DQ) a previously enqueued initiate request (See bits 2-3 for 
further specification of setup actions. ) 
Note: Value 00 is defined only for Format 1. 
O01 initiate only (I): do not enqueue 
10 enqueue only (Q) (See byte 5 for further specification of queuing condi- 
tions. ) 
ll initiate/enqueue (I/Q): enqueue the request 1f it cannot be satisfied 
immediately 
Note: Only values 01 and 11 are defined for LU 6.2. 
bits 2-3, (used for DQ; otherwise, reserved) 
00 leave on queue if setup attempt is unsuccessful 
01 remove from queue if setup attempt is unsuccessful 
10 remove from queue; do not attempt setup 
ll reserved 
bit 4, reserved 
bits 5-6, PLU/SLU specification: 
00 DLU 1s PLU 
01 DLU is SLU 
bit 7, reserved 
Queuing conditions for DLU (reserved when Type = DQ): 
bit 0, 0 do not enqueue if session limit exceeded 
1 enqueue 1f session limit exceeded 
bit 1, 0 do not enqueue 1f DLU 1s not currently able to comply with the PLU/SLU spec- 
ification (as given in byte 4, bits 5-6) 
1 enqueue 1f DLU is not currently able to comply with the PLU/SLU specifica- 
tion 
bit 2, reserved 
bit 3, reserved for LU 6.23; otherwise: 
0 do not enqueue if no SSCP(DLU)-DLU path 
1 enqueue if no SSCP(DLU)-DLU path 
bit 4, reserved 
bits 5-6, queuing position/service: 
00 put this request at the bottom of the queue (the request is put at the 
bottom of the queue and serviced last) 
01 enqueue this request FIFO (only value defined for LU 6.2) 
10 enqueue this request LIFO 
11 reserved 
bit 7, reserved 
Note: Since queuing conditions are specified for the DLU only, the following default 
values are used by SSCP(OLU) for the OLU: 
® Enqueue if session limit exceeded. 
® Enqueue this request at the foot of the queue (FIFO). 
Reserved for LU 6.23; otherwise: 
bits 0-2, reserved 
bit 3, initiator (reserved when Type = 0Q): 
0 network user ts the initiator 
1 network manager is the initiator 
bits 4-7, reserved 
NOTIFY specifications (reserved when Type = DQ and for LU 6.2): 
bits 0-1, NOTIFY(X'O1') conditions: 
00 do not notify LUs in session with DLU 
Ol reserved 
10 notify LUs in session with DLU only if request is queued 
1l reserved 
bits 2-7, reserved 
Mode name: an eight-character symbolic name (implementation and installation depend- 
ent) that identifies the set of rules and protocols to be used for the session; used 
by the SSCP(SLU) to select the BIND image that will be used by the SSCP(PLU) to build 
the CINIT request (reserved when Type = DQ) 
Uninterpreted Name of DLU 
Type: X'F3' logical unit 
Length, in binary, of DLU name 
DLU name EBCDIC character string 
Retired 
User Field (reserved when Typ» = DQ and for LU 6.2) 
Length, in binary, of user data 
Note: X'00' = no user data is present. 
User data: user-specific data that 1s passed to the primary LU on the CINIT request 
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INIT-SELF Format 1 and 2 


n+4 


n+5-r 
n+5-r 
r+l-s 
r+] 


r+2-s_ 


st+l-s+8 


User data key 
X'00' structured subfields follow 


“X'00' first byte of unstructured user data 


Note: Individual structured subfields may be omitted entirely. When present, 
they appear in ascending field number order. 


® For unstructured user data 


Remainder of unstructured user data | 


® For structured user data. 


Structured subfields (For detailed definitions, see “User Data Structured Subfield 
Formats" on page E-41.) 

User Request Correlation (URC) Field (When Type = DQ, the URC must be the same as in 
the original INIT-SELF request. ) 

Length» in binary», of URC 

Note: X'00' = no URC. (The length field is always present.) 

URC: LU-defined identifier; this value can be returned by the SSCP in a subsequent 
NOTIFY to correlate a given session to this initiating request 

End of Format 1; Format 2 Continues 

COS name: symbolic name of class of service in EBCDIC characters (A value of eight 
space characters may be specified; in this case, the COS name is derived from the mode 
name table using the mode name received in bytes 8-15.) 


NC-ER-TEST-REPLY; PU_T4|5-->PU_T4I5, EXP; NC (EXPLICIT ROUTE TEST REPLY) 


fue So 


47 


Note: 


NC-ER-TEST-REPLY is returned to signal the suc- 


cess ful or unsuccessful completion of the 
NC-ER-TEST. 


X'OA' request code 

Reserved 

Format: X'OL' Conly value defined) 

Type: 

X'00' The corresponding NC-ER-TEST reached its destination subarea 

X¥'02' ER not reversible since there is no reverse ERN defined 

X'03' Retired 

X'04' ER length exceeded the limit specified in the NC-ER-TEST request 

X'05' ER requires a TG that 1s not active 

X'06' ER is not defined in the NC-ER-TEST-REPLY originating node 

X'07' Retired 

Explicit route length, in terms of number of the transmission groups in the explicit 
route as accumulated in NC-ER-TEST. 

Maximum ER length, as specified in the NC-ER-TEST request 

Subarea address of the destination PU for corresponding NC-ER-TEST 

Reserved 

bits 0-3, reserved 

bits 4-7, ERN of the ER being tested 

Subarea address of the PU that originated the corresponding NC-ER-TEST 

Reverse ERN mask: a bit is on if the corresponding ERN can be used to route to the 
originating subarea 

Maximum PIU size permitted on the reverse ERN specified in bytes 17-18: 

X'0000' no restriction (only value defined) 

Maximum PIU size accumulated by the NC-ER-TEST: 

X'0000' no restriction (only value defined) 

Network address of the SSCP originating the corresponding NS test request 

Request correlation field: same value as specified in the corresponding NC-ER-TEST 
Subarea address of the PU that originated this NC-ER-TEST-REPLY 

Subarea address depending on the type field (byte 4) as follows: 


Type Contents of this field 

X'00' reserved 

X'02' subarea on the ER prior to that with no reverse ERN defined 

X'03' reserved 

X'04' subarea on the ER preceding the subarea where the explicit route length 


(byte 5 of NC-ER-TEST) is incremented to a value one more than the maximum 
ER length limit (byte 6) 


X'05' subarea on the other end of the TG that is not active 

X'06' subarea on the ER from which the PU (that does not have the ER defined), 
received the corresponding NC-ER-TEST 

X'07' reserved 


TGN of the TG between the subareas specified in bytes 39-42 and 43-463 reserved if 
Type is X'00' 


For nodes supporting generation of the X'LF' Control Vector; format 1 continues below: 
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NC-ER-TEST-REPLY 


One or more control vectors, as described in the section "Control Vectors" on page 

E-49 

Note: The following vector Key may be used in NC-ER-TEST-REPLY: 

X'1F' ER Configuration control vector: one X'IF' control vector is included by each 
node that supports the X'IF' control vector along the route being tested 


NOTIFY; SSCP<-->PU, Norm; FMD NS(c) (NOTIFY) 


aa? 
£m 


l2-n 


NOTIFY is used to synchronize awareness between 
the SSCP and PU of the status of a cross-network 
session. 


NOTIFY 1s sent by the SSCP to inform the PU that a 
session initiation process could not complete. It 
is sent by the PU to inform the SSCP: 


That a session initiation sequence could not 
be completed because of inability to activate 
a VR 

That SON was received for a pending or pending 
active session 

That a session terminated normally 


X'410220' NS header 

Element address of the PU, if ENA is supported; otherwise, its network address 

NOTIFY vector Key: 

X'05' cross-network session synchronism: used to maintain synchronization between the 
SSCP and the PU for the mutually supported cross-network LU-LU or SSCP-SSCP ses- 
sion identified by the Network-Qualified Address Pair (X'15') control vector 
(only value defined) 

NOTIFY vector data 

For NOTIFY vector key X'05' (for the PU-->SSCP flow) 

Cause: the PU sends NOTIFY to the SSCP when it has cleaned up the indicated 

cross-network session for the cause indicated by one of the following values: 

X'00' VR activation failure: the gateway node was unable to activate a VR from the 
VRID list contained in bytes l2-n 

X'O1' session ended: the gateway node has received a response to a cross-network 
session-deactivation request 

X'02' session-activation request rejected: the gateway node has received a negative 
response to a session activation request 

X'03' session started: the gateway node has received a positive response to a session 
activation request. 

For NOTIFY vector key X'05' (for the SSCP-->PU flow) 

Cause: the SSCP sends NOTIFY to direct the PU to clean up the tndicated cross-network 

session for the cause indicated by one of the following values: 

X'0¢' session terminated: the SSCP is forcing the deactivation of the session (for 
example, because of operator action) 

X'05' session setup failure: the SSCP has detected a session setup failure 

X'06' session takedown failure: the SSCP has detected a session takedown failure 

If byte 6 = X'O00' or X'02', this field contains the sense data from the negative 

response to a session activation request; otherwise, 1t contains 0's 

Correlation indicators: 

bit 0, retention indicator: 

0 do not retain the address pair for future use 
1 retain the address pair for potential re-use 

Note: This indicator is used on the PU-to-SSCP flow and on the SSCP-to-PU flow to 

override the retention indicator that was carried on RNAA. 

bits 1-7, reserved 

One or more control vectors, as described in the section "Control Vectors" on page 

E-49 

Note: The following vector keys may be used in NOTIFY(c): 

X'15' Network-Qualified Address Pair control vector 


Control vector X'15' is used to identify the session to which this request. 
applies and always precedes the additional control vectors, if present. 


For LU-LU sessions the addresses are PLU, SLU, respectively. 
For SSCP-SSCP sessions the addresses may be tn any order. 


@ For the SSCP-->PU flow, the addresses contained within the X'15' control 
vector are as defined below: 


Appendix E. Request-Response Unit (RU) Formats E-29 


NOTIFY 
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NAUL and NAU2 are both addresses within the network identified by the net- 
work ID field of the vector. NAU2 contains an alias address assigned within 
the gateway node receiving this vector. This order applies to the Address 
Pair session key on both the origin NAU and destination NAU side of the 
gateway node. 


Prior to the NAU Address control vector (X'1A') being received by the gate- 
way node, the X'15' control vector contains the address pair for the network 
adjacent to the gateway node PU on the origin-NAU side of the PU. After 
X'LA' has been received in the gateway node, the control vector may carry 
the session address pair on either side of the gateway node PU. 


° For the PU-->SSCP flow, the control vector identifies the session in one 
network or the other as follows: 


- When the cause code (byte 6) is X'00', VR activation failure, the con- 
trol vector identifies the session in the network of the VR activation 
failure. 


- When the cause code (byte 6) is not X'00', the control vector identifies 
the session in the network the origin-NAU side of the gateway node PU. 


X'1B" VRID List control vector (this control vector included only for the PU-to~SSCP 
flow and when byte 6 = X'00'—VR activation failure) 

Note: The following additional vector keys may be used in NOTIFY(c) sent from the PU 

to SSCP to carry information about the cross-network LU-LU sessions that have been 

activated: 

X'1E' VR-ER Mapping Data control vector 
Note: This information is the same as provided in the SESSST RUs that are sent 
by the LUs to the SSCPs with which they have active sessions. One pair of vec- 
tors (X'15' and X'1E') specify the required data for each side of the gateway 
(j.e.3; four vectors are appended to NOTIFY when the NOTIFY Vector Key field 
(byte 5) is set to X'05' and the Cause field (byte 6) is set to X'03'. These 
vectors always appear in the order X'15', X'ILE', X'15"', X'1E'. In this use of 
control vector X'15', NAU 1 is the PLU address and NAU 2 the SLU address. 


NOTIFY; SSCP-->SSCPILU, LU-->SSCP, Norm; FMD NS(s) (NOTIFY) 


Woo 
GTNN 


NOTIFY is used to send information from an SSCP to 
another SSCP or to an LU, or from an LU to an 
SSCP. NOTIFY carries information in the form of a 
(vector key, vector data) pair. 


X'810620' NS header (for SSCP-->LU and LU-->SSCP) 

X'818620' NS header (for SSCP-->SSCP) 

One NOTIFY vector as described in detail below 

Note: One of the following vector Keys 1s used: 

X%'01' Resource Requested: used to inform the current users (LUs) or actively control- 
ling SSCPs of a resource (LU) that another LU wishes to use the resource 

X'03' ILU/TLU or Third-party SSCP Notification: 
® ILU/TLU notification: used to inform the sender of an INIT or TERM request 

of the status of the session : 
® third-party notification: used to inform a third-party SSCP (the SSCP whose 
LU issued an INIT-OTHER) of the status of the setup procedure 

X'04' retired 

X'06' Cross-Gateway Resource Requested: same meaning as for X'0l1' except that the LU 
wishing to use the resource (LU) is in a subnetwork different from that of the 
‘target LU 

X'07' Resource Available: used to inform the sender of INIT (i.e., the ILU or 
SSCP(ILU)} or CDINIT that the required resource is now available. 

X'08' Cross-network Resource Available: used to inform the sender of INIT (1.e., the 
ILU or SSCP(ILU)) or CDINIT that the DLU is now available; 
Note: NOTIFY NS(s) key X'08' is used when resource availability information 1s 
subject to trial-and-error rerouting. 

X'OC' LU-LU Session Services Capabilities: used to inform the SSCP having an active 
session with the sending LU of the current LU-LU session services capability of 
that LU 


NOTIFY vectors (described zero-origin) 


Resource Requested NOTIFY Vector 


0 


Key: xX'OlL' 
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NOTIFY 


I-m Network name of requested LU 

1 Type: X'F3' logical unit 

2 Length, in binary, of symbolic name of LU 
3-m Symbolic name in EBCDIC characters. 

m+l=-n Network name of requesting LU 

mtl Type: X'F3' logical unit 

m+2 Length, tin binary, of symbolic name 

m+3-n Symbolic name in EBCDIC characters 


ILU/TLU or Third-party SSCP Notification NOTIFY Vector 
0 Key: X'03! 
1 Status: 
X'00' SSCP(OLU) and SSCP(DLU) not logically connected, i.e., no session or session 
setup path (if rerouting is required) exists between them 
X'O1' session terminated 
X'02' session set up (1.e., In the same-domain case, +RSP(SESSST) has been sent and, 
in the cross-domain case, +RSP(CDSESSST) has been sent or received) 
X%'03" procedure error 
2-9 PCID: a unique value used as a session identifier 
10 Reason (defined for Status field value of X'03' only) 
Note: There are two encodings of the Reason byte: 
e If bit 4 = 0, then the Reason byte is encoded for a setup procedure error. 
© If bit 4 = 1, then the Reason byte is encoded for a takedown procedure error. 
Setup Procedure Error 
bit 0, 1 CINIT error in reaching the PLU 
bit 1, 1 BIND error in rerching the SLU 
bit 2, 1 setup reject at the PLU 
bit 3, 1 setup reject at the SLU 
bit 4, 0 setup procedure error 
bit 5, reserved 
bit 6, 1 setup reject at SSCP 
bit 7, reserved 
Takedown Procedure Error 


bit 0, 1 CTERM error in reaching the PLU 
bit 1, 1 UNBIND error in reaching the SLU 
bit 2) 1 takedown reject at the PLU 

bit 3, 1 takedown reject at the SLU 

bit 4, 1 takedown procedure error 

bit 5, 1 takedown reject at the SSCP 


bit 6, 0 see following Note 
bit 7, reserved 
Note: The bit combination of 11 for bits 4 and 6 is set aside for implementa- 
tion internal use and will not be otherwise defined. 
11-14 Sense data (defined for Status value of X'03' only) 
15-m Session Key, as described in the section "Session Keys" on page E-58 
Note: One of the following session keys is used: 
X'06' network name pair: (PLU or OLU or LUL) and (SLU or DLU or LU2), respectively 
X'07' network address pair: PLU and SLU, respectively 
X'OA’ URC 
Note: This session key is applicable within a NOTIFY only for SSCP-to-TLU; it 
is ‘the URC carried in the Session Key field (as opposed to the URC field) in 
TERM, and differs from the URC in bytes m+l through n below. 
X'15' network-qualified address pair: PLU and SLU, respectively 


mt+l-n User Request Correlation (URC) Field 
m+l Length» in binary, of the URC 
m+2-n URC: LU-defined identifier, specified in an INIT or TERM request; used to correlate 


the NOTIFY to the initiating or terminating requests 
Note: The URC length is 0 for SSCP-to-SSCP. 


Cross-Gateway Resource Requested NOTIFY Vector 
0 Key: X'06' 
l-m Three control vectors (as described in the section "Control Vectors" on page E-49) are 
used in NOTIFY key X'06' to identify the LUs involved in the resource request: 
X'19' Resource Identifier control vector: identifies the current session partner of 
the requested LU and is the target LU 
X'19' Resource Identifier control vector: identifies the requested LU 
X'19' Resource Identifier control vector: identifies the requesting LU 
Note: If the length 1s 0, the indicated LU name 1s unavailable. 


Resource Available NOTIFY Vector 
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Key: X'07" 

Sense data: same as returned in corresponding -RSP(CDINIT) 

Session key, as described in the section, "Session Keys" on page E-58 

Note: One of the following session Keys is used: 

X'O1' Network Name or Uninterpreted Name: this session Key (X'01') identifies the DLU 
of an earlier CDINIT request that failed because of the unavailability of a 
required resource. Session key X'01' is used to signal the general availability 
of the resource to any and all LUs in the domain of the SSCP being notified. 
Note: This session Key (X'01') is applicable within a NOTIFY (X'07') only for 
SSCP-to-SSCP. 


Cross-Gateway Resource Available NOTIFY Vector 


0 


1l- 


4 


5-m 


Key: X'08' 
Sense data: same as returned in corresponding -RSP(CDINIT) 

The following two control vectors are used in NOTIFY NS(s) key X'08' to identify the 
target resource being notified and the DLU of an earlier CDINIT request that failed 
because of the unavailability of a required resource. The vector identifying the tar- 
get resource appears first. 

X'17' SSCP Identifier control vector: identifies the SSCP being notified of the gen-. 
eral availability of a resource required for a successful session setup with the 
DLU specified in the accompanying X'19' control vector. The SSCP identified 
herein is the target SSCP. 

X'19' Resource Identifier control vector: identifies the LU that was earlier named as 
the DLU in a CDINIT request that could not be satisfied due to the 
unavailabilitly of a resource that has since become available. 


LU-LU Session Services Capabilities NOTIFY Vector 


PEs 
3 


“VN Ul ul 


8-15( =m) 


Key: X'0C' 
Length, in binary, of Vector Data field 


Vector Data 


bits 0-3, primary LU capability: 
0000 PLU capability is inhibited, sessions can neither be queued nor started 
0001 PLU capability is disabled, sessions can be queued but not started 
0010 reserved 
0011 PLU capability is enabled, sessions can be queued or started 
bits 4-7, secondary LU capability: 
0000 SLU capability is inhibited, sessions can neither be queued nor started 
0001 SLU capability is disabled, sessions can be queued but not started 
0010 reserved : 
0011 SLU capability is enabled, sessions can be queued or started 
LU-LU session limit (where a value of 0 means that no session limit is specified) 
LU-LU session count: the number of LU-LU sessions that are not reset, for this LU, 
and for which SESSEND will be sent to the SSCP | 
bit 0, parallel session capability: 
0 parallel sessions not supported 
1 parallel sessions supported 
bit 1, retired | 
bit 2, reserved in NOTIFY(s); SESSST capability in RSPCACTLU): 
O SESSST RU is suppressed if SLU 
1 SESSST RU is sent if SLU 
bits 3-6, reserved 
bit 7, boundary function network address pair (X'15') session key support (reserved 
for peripheral nodes): 
0 boundary function does not support session key X'15' 
1 boundary function does support session key X'15' 
Note: Boundary function support for session key X'15' cannot be changed after 
RSP(ACTLU); in NOTIFY, the sender sets bit 7 to 0, which is then ignored by 
_the receiver. 
Retired (set to X'4040404040404040') or omitted 


REQACTCDRM; PU-->SSCP, Exp; FMD NS(c) CREQUEST ACTIVATION OF CROSS-NETWORK RESOURCE MANAGER) 


REQACTCDRM prompts the receiving SSCP to issue 
RNAA and SETCV to set up a cross-network address 


transform. ACTCDRM will then be sent to activate 
an SSCP-SSCP session with the other-network SSCP 
identified in this request. 


X'41028A' NS Header 

Reserved 

Format: X'OL' Conly value defined) 
Activation subfunction indicators: 
bit 0, transform setup requirement 


NY 
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REQACTCORM 


0 transform setup not required; the addresses are left over from a previous 
session setup request 
1 RNAA required to set up a cross-network address transform 
bit 1, VRID list setup required: 
0 SETCV not required with VRID list 
1 SETCV required with at least one VRID list 
bits 2-7, reserved 
Session key, as described in the section, "Session Keys" on page E-58 


Note: The following session Key is used: 


X'15' network-qualified address pair: sending SSCP's real address and target SSCP's 
alias addresses, respectively, in the address space defined by the network ID 

Received ACTCDRM that failed because of incomplete gateway node transform: This field 

contains the received TH, RH, and the complete ACTCDRM RU (including control vectors). 


RNAA; SSCP-->PU_T415, Norm; FMD NS(c) (REQUEST NETWORK ADDRESS ASSIGNMENT ) 


aS 


RNAA requests the PU to assign element addresses: 


® To one or more adjacent link stations and 
their BF.PUs, as identified in the RNAA 
request by a link element address and second- 
ary link station link-level addresses 
To one or more BF.LUs, where the BF.LUs are 
identified in the RNAA request by an adjacent 
link station element address and the LU local 
addresses 
To an LU that supports parallel sessions; in 
order to assign an additional element address 
the LU is identified in the RNAA request by 
the LU element address used for the SSCP-LU 
session—the PU returns the element addresses 
in the RNAA response 
As alias addresses for a cross-network 
SSCP-SSCP or LU-LU session, where the name 
pair and session characteristics are identi- 
fied in the RNAA request 


If ENA 1s not supported on this SSCP-to-PU_T4/15 
session, the entire network address is in each 
Element Address field throughout this RU. 


X'410210' NS header 

Element address of target link, adjacent link station, LU, or PU 

Assignment type: 

X'00' request is for element address assignment of adjacent link station(s) associated 
with target link 

X'O1' request 1s for element address assignment of BF.LU(s) associated with the target 
adjacent link station; the address must be pre-ENA compatible 

X'02' request is for an additional element address assignment for the target LU; bytes 
3-4 contain the LU element address used in the SSCP-LU session; the address must 
be pre-ENA compatible 

X'03' request is for cross-network address transform , 

X'L1L' request is for element address assignment of BF.LU(s) associated with the target 
adjacent link station; an address that 1s ENA compatible is preferred 

X'12' request is for an additional element address assignment for the target LU; bytes 
3-4 contain the LU element address used in the SSCP-LU session; an address that 
is ENA compatible is preferred 

X'21' request is for element address assignment of 'BF.LU(s) associated with the target 
adjacent link station; an address that is pre-ENA compatible is preferred 

X'22' request is for an additional element address assignment for the target LU; bytes 
3-4 contain the LU element address used in the SSCP-LU session; an address that 
is pre-ENA compatible is preferred 

Number of element addresses to be assigned 

For Assignment Type X'00' 

Reserved 

DLC header link station address associated with the adjacent link station for which an 

element address is requested 

For Assignment Types X'01', X'IL', and X‘'21' 

Reserved 

Local address of a BF.LU for which an element address is requested, where the local 

address has either the one-byte format of FID2 or the six-bit local address format of 

FID3 (in which case, bits 0-1 of byte 8 are reserved) 


® For Assignment Types X'02', X'1l2'», and X‘'22' 
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Reserved 
Any additional two-byte entries in the same format as bytes 7-8 for assignment types 
X'00' and X'01' (not present for assignment type X'02') 
For Assignment Type X'03' 
Session characteristics 
Note: For an SSCP-SSCP session, origin-NAU and destination-NAU refer to the SSCP that 
sent RNAA and to the target SSCP, respectively. The parallel session indicators spec- 
ify that the SSCPs do not have the capability to support parallel SSCP-SSCP sessions 
(byte 7, bit 0 and bit 1 = 0) 
bit 0, parallel session capability of the adjacent SSCP on the origin-NAU side of the 
PU: 
0 SSCP does not have parallel session capability 
1 SSCP does have parallel session capability 
bit 1, parallel session capability of the adjacent SSCP on the destination-NAU side 
of the PU: 
0 SSCP does not have parallel session capability 
1 SSCP does have parallel session capability 
bit 2, primary/secondary nature of OLU (reserved for session type = SSCP-SSCP, j.e., 
bit 4 = 1): 
0 OLU=PLU 
1 OLU=SLU 
bit 3, retention flag: 
0 do not retain address transform after session termination 
l1 retain address transform after session termination 
bit 4, session type: 
0 LU-LU session 
1 SSCP-SSCP session | 
bit 5, ENA capability of adjacent SSCP on origin NAU side of PU: 
0 must be pre-ENA compatible 
1 may be ENA compatible 
bit 6, ENA capability of adjacent SSCP on destination NAU side of PU: 
0 must be pre-ENA compatible 
l may be ENA compatible 
bit 7, reserved 
Reserved . 
Origin-NAU's (real) address as known in the network adjacent to the PU and on the 
origin-NAU side of the PU 
Network ID of the network adjacent to the PU, on the origin-NAU side of the PU 
Network ID of network adjacent to the PU, on the destination-NAU side of the PU 
Network ID of the origin-NAU's network 
Length of origin-NAU name 
Origin-NAU's (real) name 
Network ID of the destination-NAU's network 
Length of the destination-NAU name 
Destination-NAU's (real) name 


ROUTE-INOP; PU-->SSCP, Norms; FMD NS(€c) CROUTE INOPERATIVE ) 


ROUTE-INOP notifies the CP when either a virtual 
or an explicit route has become inoperative as the 


result of a transmission group having become inop- 
erative somewhere in the network. 


X'410289' NS header 

Format: X'OlL' (only value defined) 

Reason code: 

X'O1' unexpected routing interruption over a transmission group; e.g., the last active 
link in a TG has failed 

X'02' controlled routing interruption, such as the result of DISCONTACT 

Subarea address of the PU that originated the NC-ER-INOP 

Subarea address on other end of the transmission group that had the routing inter- 

ruption 

Subarea address at the route origin 

Note: This is the subarea address of the sender in the address space as defined by 

the network ID contained in bytes 18-25. 

TGN of the transmission group that had the routing interruption 

Network ID of the subnetwork in which this inoperative report applies 

Note: If the Network ID field contains all space (X'40') characters, the reported 

route is tn the receiver's own subnetwork 

Number of Route fields that follow 

Route Field 

Subarea address for which routing has been interrupted 

ER mask: a bit 1s on for each ER to the destination subarea identified | in bytes 27-30 

for which routing has been interrupted (Bit n corresponds to ERN n) 
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33-34 


35-42 


G3-m 


ROUTE-INOP 


VR mask: a bit 1s on for each VR to the destination subarea identified in bytes 27-30 
for which routing has been interrupted (Bit n corresponds to VRN n} 

VR-to-ER mapping list: each 4-bit field. (16 fields in all) corresponds to a VR number 
and contains the ERN to which that VR number is assigned (If field 0 contains B'0010', 
VRO assigned to ER 2 has failed.) 

Additional Route fields in the same format as bytes 27-42 


ROUTE-TEST; SSCP-->PU_T415, Norm; FMD NS(ma) (ROUTE TEST) 


SESSEND 5 


4-8 


ROUTE-TEST requests the PC_ROUTE_MGR component of 
PU.SVC_MGR to return the status (for example, 


active, operative, not defined), as known in the 
control blocks in the node, of various explicit 
and/or virtual routes. 


X'410307' NS header 

Element address of PU originating the test (as Known in the sender's subnetwork), if 
ENA 1s supported; otherwise, its network address 

Format: X'O1' (only value defined) 

Test code: 

X'O1' test regardless of the states of ERs 

X'02' test each ER that is not inoperative 

X'03' test each ER that is inoperative 

X'04' do not test the ER; respond with the current ER state (See RSPC(ROUTE-TEST )) 


Choice of routes to be tested: 


X'01' test the ERs corresponding to the ERNs specified in bytes 15-16 and also report 
the status of the VRs supported by these ERs 
X'02' test the VRs corresponding to the VRNs specified in bytes 15-16; byte 6 applies 
to the underlying ERs for the VRs; these ERs are also tested 
X'03' test the ERs corresponding to the defined TG for the ERNs specified in bytes 
15-16 and also report the status of the VRs supported by these ERs 
bits 0-5, reserved 
bits 6-7, transmission priority for NC-ER-TEST (reserved if the value of byte 6 is 
X'04"): 
00 low priority 
O01 medium priority 
10 high priority 
Reserved 
Maximum expected ER length of any ER being tested 
Subarea address of destination PU for the NC-ER-TEST request 
A bit is on if the corresponding ERN or VRN (depending on the route type specified in 
byte 7) is to be tested (Bit 0 corresponds to ERN or VRN 0, bit 1 to ERN or VRN 1, and 
so forth.) 
Request correlation field: an implementation-defined value that is returned in 
ER-TESTED for correlation of reply to request 
Network ID of the subnetwork wherein the route to be tested resides 
Note: If the Network ID field contains all space (X'40...40') characters, the route 
to be tested is in the sender's own network. 


LU-->SSCP, Norm; FMD NS(s) (SESSION ENDED) 


SESSEND is sent, with no-response requested, by 
the LU (or boundary function on behalf of the LU 
in a peripheral node) to notify the SSCP that the 


session between the specified LUs has been suc- 
cessfully deactivated. 


X'810688' NS header 
bits 0-3, format: 
0000 format 0 (supported only for nodes that are not at the current level of 
SNA) 
0010 format 2 
bits 4-7, reserved 
Format 0 
Session key, as described in the section "Session Keys" on page E-58 
Note: The following session key is used: 
X'07' network address pair: PLU and SLU, respectively (only value defined) 
Format 2 
Cause: indicates the reason for the deactivation of the LU-LU session (see UNBIND for 
values ) 
Action: indicates if any resultant action is to be taken and by whom: 
X'OL' normal, no resultant automatic action fonly value defined for LU 6.2) 
X'02' primary half-session will restart 
X'03' secondary half-session will restart 
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SESSEND 


6-n Session key, as described in the section "Session Keys" on page E-58 
Note: One of the following session keys is used: 
X'06' network name pair: PLU and SLU; respectively 
X'07' network address pair: PLU and SLU, respectively 
X'15" network-qualified address pair: PLU and SLU, respectively 
Note: Only session keys X'07' and X'15' are defined for LU 6.2. 


SESSST$; LU-->SSCP, Norm; FMD NS(s) (SESSION STARTED) 


SESSST is sent, with no response requested, by the 
LU (or the boundary function on behalf of the LU 
in a peripheral node) to notify the SSCP that the 
session between the specified LUs has been suc- 
cessfully activated. 


0-2 X'810686' NS header 
3 Format: 
X'00' Format 0: no control vectors present 
X'OL' Format 1: control vectors present in bytes ntl-p 
4-n Session key, as described in the section "Session Keys" on page E~58 
Note: One of the following session keys is used: 
X'07' network address pair: PLU and SLU, respectively 
X'15' netuork-qualified address pair: PLU and SLU, respectively 


Note: End of Format 03; Format 1 continues below 


ntl-p One or more control vectors, as described in the section "Control Vectors" on page 
E-49 
Note: The following vector keys may. be used in SESSST: 
X'1LE' VR-ER Mapping Data 
X'23' Local Form Session Identifier 


SETCV; SSCP-->PU_T415, Norms; FMD NS(c) (SET CONTROL VECTOR) 


SETCV sets a control vector that is maintained by 
the PU receiving the request and that is associ- 


ated with the network address specified in the RU. 


0-2 X'010211' NS header 

3-4 Element address of resource to which control vector applies, if ENA is supported; oth- 
eruise, its network address 
Note: For control vectors X'15", X'16', X'1LA', and X'1B', this field contains the PU 
address, and the X'15' control vector identifies the cross-network session to which 
the data contained in control vectors X'16',) X*IA', and X'1B' apply. 

5-n One or more control vectors, as described in the section "Control Vectors" on page 


E-49 

Note: The following vector keys may be used in SETCV (configuration services): 

X'OL': Date-Time 

X'02': Subarea Routing 

X'03': SDLC Secondary Station 

X'04': LU 

X'05': Channel 

X'15': Network-Qualified Address Pair 

X'16'": Names Substitution 

X'IA': NAU Address 

X'1B': VRID List 

Note: See SNA Reference Summary for the formats of the first five control vectors 
mentioned above. They are not related to gateway services. 

Note: The following table shows the relationship between the control vector included 
and the resource identified in bytes 3 and 4. 


Key (Byte 5) Resource (Bytes 3-4) 


X'OL' PU | 

X'02' Link to be used for routing to the subarea specified in byte 6 
Xx'03' SPU 

X'04' LU 

x'05' Link ($7370 channel ) 

X'15' PU 

x'16' PU 

X'1A' PU 

X'1B' PU 
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SETCV 


Note: Control vector X'15' is used to identify the session to which vectors X'16', X'1A and 
X'IB' apply and precedes these vectors. The addresses contained within this X'15' control vec- 
tor are as defined below: 


NAU I and NAU 2 are both addresses within the network carried in the network ID field of the 
vector. NAU 2 contains an alias address assigned within the gateway node receiving this vector. 
This order applies to the address pair session key on both the origin NAU and destination NAU 
side of the gateway node. 


Prior to the X'ILA' vector being received by the gateway node, the X'15' control vector contains 
the address pair for the network adjacent to the gateway node PU on the origin-NAU side of the 
PU. After X'1A' has been received in the gateway node, the X'15' control vector may carry the 
session address pair on either side of the gateway node PU. 


TERM-OTHER; TLU-->SSCP, Norm; FMD NS(s )( TERMINATE-OTHER ) 


TERM-OTHER from the TLU requests that the SSCP 
assist in terminating session(s) between the two 
LUs named in the RU. The requester may be a third 


party LU or one of the two named LUs. This RU is 
not used by LU 6.2, although it can be used by a 
third-party LU for LU 6.2. 


0-2 X'810682' NS header 
3 bits 0-3, Format: 
O00! Format 1 (Only value defined) 
bits 4-7, reserved 
4 Type 
bits 0-1, 00 the request applies to active and pending-active sessions 
01 the request applies to active, pending-active, and queued sessions 
10 the request applies to queued sessions only 
1l the request applies to pending-active and queued sessions only 
bit 2, reserved if byte 4, bit 7 = 13 otherwise: | 
0 forced termination—session to be deactivated immediately and. uncondi- 
tionally | 
1 orderly termination—permitting an end-of-session procedure to be executed 
at the PLU before the session is deactivated 
bit 3, 0 do not send DACTLU to LUI; another session initiation request will be sent 
for LUI 
1 send DACTLU to LUL when appropriate; no further session initiation request 
will be sent (from this sender) for LUI 
bit 4, 0 do not send DACTLU to LU2; another session initiation request will be sent 
for LU2 
1 send DACTLU to LU2 when appropriate; no further session initiation request 
will be sent (from this sender) for LU2 
bits 5-6, session selection (reserved when session Key X'06' not used) 
00 select session(s) for which LULL is PLU 
01 select session(s) for which LU2 is PLU 
10 select session(s) regardless of whether LU is PLU or SLU 
1l reserved 
bit 7, 0 orderly or forced (see byte 4, bit 2) 
1 cleanup 
5 Reason 
bit 0, 0 network user 
1 network manager 
bit 1, 0 normal termination 
1 abnormal termination 
bits 2-7, reserved 
6 NOTIFY specifications: 
bits 0-5, reserved 
bit 6, NOTIFY(X'03') condition 
0 do not notify TLU when the session takedown procedure is complete 
l notify the TLU when the session takedown procedure is complete 
bit 7, reserved 
7 Type extension (see byte 4) 
X'00' terminate specified session and perform notification based on the NOTIFY spec- 
ification (byte 6) 
X'O1' do not terminate specified session, but perform notification based on the NOTIFY 
specification (byte 6) 
X'02' retired 
X'03' retired 
8-n Session key, as described in the section "Session Keys" on page E-58 
Note: One of the following session keys is used: 
X'06' network name pair 
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TERM-OTHER 


Note: If the length of one of the names (LUL or LU2, but not both) is 0 then 
all sessions for the named LU, as specified by the Type byte, are terminated as 
a result of this TERM-OTHER request. 

X'07' network address pair: PLU and SLU, respectively 

X'OA* URC 
Note: This URC is the one carried in the INIT issued previously by the same LU 
(i.e., ILU = TLU), and differs from the one in bytes n+4 through p. 

X'15' network-qualified address pair: PLU and SLU, respectively 

ntl-n+2 Retired 


n+3-p User Request Correlation (URC) Field 
n+3 Lengths in binary, of the URC 
Note: X'00' = no URC. 
n+4-p URC: LU-defined identifier; this value can be returned by the SSCP in a subsequent 


NOTIFY to correlate the NOTIFY to this terminating request 


TERM-SELF$ TLU-->SSCP, Norm; FMD NS(s) (TERMINATE-SELF ) 


TERM-SELF from the TLU requests that the SSCP 
ass1st in the termination of one or more sessions 
between the sender of the request (TLU = OLU) and 


the DLU. This RU is not used for LU 6.23 refer to 
TERM-SELF Format 1. 


0-2 X'010683' NS header 
3 Type: 
bits 0-1, 00 the request applies to active and pending-active sessions 
01 the request applies t» active, pending-active, and queued sessions 
10 the request applies to queued only sessions 
ll reserved 
bit 2, reserved if byte 3, bit 4 = 13 otherwise: 
0 forced termination—session to be deactivated immediately and uncondi- 
tionally 
1 orderly termination—permitting an end-of-session procedure to be executed 
at the PLU before the session is deactivated 
bit 3, 0 do not send DACTLU to OLU; another session initiation request will be sent 
for OLU 
1 send DACTLU to OLU when appropriate; no further session initiation request 
will be sent (from this sender) for OLU 
bit 4, 0 orderly or forced (see byte 3, bit 2) 
1 clean up 
bits 5-6, 00 select session(s) for which DLU is PLU 
01 select session(s) for which DLU is SLU 
10 select session(s) regardless of whether DLU is SLU or PLU 
ll reserved 
bit 7, 0 indicates that the format of the RU is Format 0 and that byte 3 is the Type 
byte. 
-m Uninterpreted Name of DLU 
Type: X'F3' logical unit 
Length, in binary, of DLU name 
Note: If the length value of the DLU name is 0, then the TERM-SELF applies to all 
sessions, as specified in the Type byte, where the TLU is a partner. 
6-m EBCDIC character string 
Note: The following defaults are supplied by the SSCP receiving a Format 0 TERM-SELF: 


Uf 


® Reason: network user, normal 
° Notify: do not notify 
e URC is not used in mapping to subsequent requests. 


TERM-SELF$ TLU-->SSCP, Norm; FMD NS(s) (TERMINATE-SELF ) 


TERM-SELF from the TLU requests that the SSCP 
assist in the termination of one or more sessions 


between the sender of the request (TLU = OLU) and 


the DLU. 
0-2 X'810683' NS header 
3 bits 0-3, format: 


0001 Format 1 (only value defined) 
bits 4-6, reserved 
bit 7, 1 indicates that byte 3, bits 0-3, contain the format value 
4 Type: 
bits 0-1, 00 the request applies to active and pending-active sessions 
01 the request applies to active, pending-active, and queued sessions (only 
value defined for LU 6.2) 
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n+l-nt+2 
n+3-p 
n+3 


nt+4-p 


TERM-SELF Format 1 


10 the request applies to queued sessions only 
ll reserved 


bit 2, reserved if byte 4, bit 7 = 13 otherwise: 


bit 


0 forced termination—session to be deactivated immediately and uncondi- 
tionally 

1 orderly termination—permitting an end-of-session procedure to be executed 
at the PLU before the session is deactivated 


3, 0 do not send DACTLU to OLU; another session initiation request will be sent 


for OLU 
1 send DACTLU to OLU when appropriate; no further session initiation request 
will be sent (from this sender) for OLU (only value defined for LU 6.2) 


bit 4, reserved 
bits 5-6, 00 select session(s) for which DLU is PLU 


01 select session(s) for which DLU is SLU 
10 select session(s) regardless of whether DLU is SLU or PLU 
11 reserved 


bit 7, 0 orderly or forced (see byte 4, bit 2) 


1 clean up 


Reason: 
bit 0, 0 network user (only value defined for LU 6.2) 


bit 


1 network manager 


1, 0 normal termination 


1 abnormal termination 


bits 2-7, reserved 

NOTIFY specifications (reserved for LU 6.2): 

bits 0-5, reserved 

bit 6, 0 do not notify TLU when the session takedown procedure is complete 


l notify the TLU when the session takedown procedure is complete 


bit 7, reserved 
Reserved 
Session key, as described tn the section "Session Keys" on page E-58 


Note: 
xX'O1' 


X'07' 
X'OA' 


X'15' 


One of the following session keys is used: 
uninterpreted name 

Note: If the length value is 0, then the TERM-SELF applies to all sessions 
specified in the Type byte where the TLU its a partner. 

network address pair: PLU and SLU, respectively 

URC (only session key defined for LU 6.2) 

Note: This URC is the one carried in the INIT tssued previously by the same LU 
(i.e., ILU = TLU), and differs from the one in bytes n+#4 through p. 
network-qualified name pair: PLU and SLU, respectively 


Retired: set to X'0000' 
User Request Correlation (URC) Field 
Length, in binary, of URC field 


Note; 
URC: 


X'OO" = no URC. 
LU-defined identifier; this value can be returned by the SSCP in a subsequent 


NOTIFY to correlate the NOTIFY to this terminating request 


UNBIND; LU-->LU, Exp; SC (UNBIND SESSION) 


X'32' 


! UNBIND is sent to deactivate an active session 
between the two LUs. 


request code 


Type UNBIND: 


X'oL' 
X'02' 


X'06' 


X'07' 


X'08' 


x'09' 


X'O0A' 


X'OB* 


normal end of session 

BIND forthcoming; retain the node resources allocated to this session, if possi- 
ble 

invalid session parameters: the BIND negotiation has failed due to an inability 
of the primary half-session to support parameters specified by the secondary 
virtual route inoperative: the virtual route used by the LU-LU session has 
become inoperative, thus forcing the deactivation of the identifed LU-LU session 
route extension inoperative: the route extension used by the LU-LU session has 
become inoperative, thus forcing the deactivation of the identified LU-LU ses- 
sion 

hierarchical reset: the identified LU-LU session is being deactivated because 
of a +RSPCCACTPU | ACTLU), Cold) 

SSCP gone: the identified LU-LU session had to be deactivated because of a 
forced deactivation of the SSCP-PU or SSCP-LU session (e.g., DACTPU, DACTLU, or 
DISCONTACT ) 

virtual route deactivated: the identified LU-LU session had to be deactivated 
because of a forced deactivation of the virtual route being used by the LU-LU 
session 
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UNBIND 


E-40 


2-5 


UNBINDF ; 


ion saad 
orn 


X'0c' 


X'OE' 


X' OF! 


X'11' 


X'FE! 


LU failure—unrecoverable: the identified LU-LU session had to be deactivated 
because of an abnormal termination of the PLU or SLU; recovery from the failure 
was not possible 

LU failure—recoverable: the identified LU-LU session had to be deactivated 
because of an abnormal termination of one of the LUs of the session; recovery 
from the failure may be possible 

cleanup: the LU sending UNBIND is resetting its half-session before receiving 
the response from the partner LU 

gateway node cleanup: a gateway node is cleaning up the session because a gate- 
way SSCP has directed the gateway node (via NOTIFY) to deactivate the session 
(e.g.» a session setup error or session takedown failure has occurred) 

format or protocol error: the LU sending UNBIND has detected a format or proto- 
col error; the error is identified by the associated sense code 


Sense data (included only when Type = X'FE'$ otherwise, this field is omitted): same 
value as generated at the time the error was originally detected (e.g., for a negative 
response, receive check, or EXR) 


PLU-->SSCP, Norms; FMD NS(s) CUNBIND FAILURE ) 


UNBINDF is sent, with no-response requested, by 
the PLU to notify the SSCP that the attempt to 
deactivate the session between the specified LUs 
has failed (for example, because of a path fail- 
ure). 


X'810687' NS header 
Sense data 

Reason: 

bit 0, reserved 


bit 


1, 1 UNBIND error in reaching SLU 


bit 2, 1 takedown reject at PLU 
bits 3-7, reserved 
Session key, as described in the section ''Session Keys" on page E-58 


Note: 


X'07" 
X'15' 


One of the following session keys 1s used: 
network address pair: PLU and SLU, respectively 


_network-qualified address pair: PLU and SLU, respectively 
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User Data Subfields 


USER DATA STRUCTURED SUBFIELD FORMATS 


COROT ENON REREAD EECA STRATES SSS EIDE 


The structured subfields of the User Data field are defined as follows (shown with zero-origin 
indexing of the subfield bytes—see the individual RU description for the actual displacement 
within the RU). Each subfield starts with a one-byte binary Length field and is identified by a 
subfield number in the following byte. The length does not include the Length byte itself. 
When more than one subfield is included, they appear in ascending order by subfield number. 


For LU type 6.2, the Structured User Data field of BIND and RSP(BIND) may contain the Unformat- . 
ted Data, Mode Name, Fully Qualified PLU Network Name, Fully Qualified SLU Network Name, and 
Session Instance Identifier subfields. Any subfields received in the Structured User Data field 
of BIND that are not recognized by the SLU are discarded and not returned as part of the Struc- 
tured User Data field of the RSP(BIND). 


Unformatted Data Structured Data Subfield 


The Unformatted Data subfield may optionally be 
sent in BIND, RSP(BIND), or any of the INITIATE 


RUs. The content is implementation-defined. 


0 Length of the remainder of the Unformatted Data subfield: values 1 to 17 (X'I1') are 
valid for LU 6.23; otherwise, values 1 to 65 (X'41') are valid 

1 X'O0' 

2-n Unformatted data: a type-G symbol string 


Session Qualifier Structured Data Subfield 


The Session Qualifier subfield is used for LU 6.1. 
It may be carried if BIND, RSP(BIND), or any of 


the INITIATE RUs. 


0 Length of the remainder of the Session Qualifier subfield (If Session Qualifier sub- 
field is present, values 3 to 19 (X'13') are valid.) 

1 X'Ol' 

2 Length of primary resource qualifier: values 0 to 8 are valid (X'00' means no primary 
resource qualifier is present) 

3-m Primary resource qualifier 

m+1 Length of secondary resource qualifier: values 0 to 8 are valid (X'00' means no sec- 
ondary resource qualifier is present) 

m+2-n Secondary resource qualifier 


Mode Name Structured Data Subfield 


The Mode Name subfield is present in both BIND and | 
RSP(BIND) if the PLU knows the mode name being | 
used by the session. 


Length of the remainder of the Mode Name subfield: values 1 to 9 are valid 


0 
1 X'02' 
e-n Mode name: 0 to 8 type-A symbol string characters with optional (but not significant) 


trailing blanks 


Session Instance Identifier Structured Data Subfield 


| The Session Instance Identifier subfield may be | 
present in both BIND and RSP(BIND). 


0 Length of the remainder of the Session Instance Identifier subfield: values 3 to 9 
are valid 

1 X'03' 

2-n Session instance identifier: a type-G symbol string 


Note: In BIND, the PLU sets a unique session instance identifier of length 1 to 7 and 
appends it to X'00'. If Known, the SLU compares its fully qualified name with that of 
the PLU; if the PLU name > SLU name then the SLU changes the first byte of the Session 
Instance Identifier subfield in the response from X'00' to X'FO', if the PLU name < 
SLU name then the subfield is simply echoed. 


Fully Qualified PLU Network Name Structured Data Subfield 
BIND contains the Fully Qualified PLU Network Name 
subfield (if the name is Known by the PLU). 
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User Data Subfields 


0 Length of the remainder of the Fully Qualified PLU Network Name subfield: values 2 to 
18 (X'1l2') are valid | 

1 X'04' 

e-n Fully qualified PLU network name 


Note: The fully qualified PLU network name is 1 to 17 bytes in length, consisting of 
an optional 1- to 8-byte network ID and a 1l- to 8-byte LU name, both of which are 
type-A symbol strings. When present, the network ID is concatenated to the left of 
the LU name, using a separating period and having the form "NWID.NAME"; when the net- 
work ID is omitted, the period is also omitted. 


Fully Qualified SLU Network Name Structured Data Subfield 


The RSP(BIND) contains the Fully Qualified SLU 
Network Name subfield (if the name is Known by the 


SLU). 
0 Length of the remainder of the Fully Qualified SLU Network Name subfield: values 2 to 
18 (X'12') are valid 
1 X'O5' 
e-n Fully qualified SLU network name 


Note: The fully qualified SLU network name is 1 to 17 bytes in length, consisting of 
an optional 1- to 8-byte network ID and a 1l- to 8-byte LU name, both of which are 
type-A symbol strings. When present, the network ID is concatenated to the left of 
the LU name, using a separating period and having the form "NWID.NAME"$ when the net- 
work ID is omitted, the period is also omitted. 


Clear Data Structured Data Subfield 


The Clear Data subfield contains the random data 
used in session-level security verification. When 


session-level security verification is in effect, 
this subfield is present in both BIND and 
RSP( BIND). 


Length of the remainder of the Clear Data subfield: 10 is the only valid value 


0 

1 X'11' 

2 Reserved 

3-10 Clear data: a type-G random value generated for subsequent checking in RSPC(BIND) or 
FMH-12 


Enciphered Data Structured Data Subfield 


The Enciphered Data subfield is present in” the 


RSP(BIND) when session-level security verification 
is in effect. This subfield contains the enci- 
phered version of the clear data received in BIND. 


Length of the remainder of the Enciphered Data subfield: 9 is the only valid value 


0 
1 X'12' 
2-9 Enciphered version of the Clear Data field carried in BIND (using the DES algorithm 


and the installation-defined LU-LU password as the cryptographic key) 


E-42 Systems Network Architecture Format and Protocol Reference Manual: SNA Network Interconnection 


SUMMARY OF RESPONSE RU'S 


POSITIVE 


Apart from the exceptions cited below, response RUs return the number of bytes specified in the 
following table; only enough of the request RU is returned to include the field-formatted 
request code. 


RU Category of Response Number of Bytes in RU 
DFC I 
sc 1 
NC 1 
FMD NS (FI=1) (field-formatted) 3 
FMD NS (FI=0) (character-coded) 0 
FMD (LU-LU) | 0 


Various positive response RUs return additional data. See "Positive Response RU's with Extended 
Formats" for details. 


All negative responses return four bytes of sense data in the RU, followed by either (1) the 
number of bytes specified in the table above or (2) three bytes (or the entire request RU, if 
shorter than three bytes). The second option applies to PU.SVC_MGR.CSC_MGR and PC (where a sen- 
sitivity to SSCP-based sessions versus LU-LU sessions does not necessarily exist) and can be 
chosen for other layers for implementation simplicity. Refer to Appendix G for sense data val- 
ues and their corresponding meanings. | 


RESPONSE RU'S WITH EXTENDED FORMATS 


RSPC(ACTCDRM)$ SSCP-->SSCP, Exp; SC 


ee, 


0 X'14' request code 
1 bits 0-3, format: X'0' (only value defined) 
bits 4-7, type activation performed: 
X'1' cold 
X'2' ERP 
2 FM profile 
3 TS profile 
4-11 Contents ID: eight-character EBCDIC symbolic name that represents implementation and 


installation dependent information about the SSCP issuing the response to ACTCDRM;3 

eight space (X'40') characters 1s the value used if no information 1s to be conveyed 

(This field could be used to provide a check for a functional and configurational 

match between the SSCPs.) 
12-17 SSCP ID: a six-byte field that includes the ID of the SSCP issuing the ACTCDRM 

response; the first four bits specify the format for the remaining bits: 

bits 0-3, 0000 

bits 4-7, physical unit type of the node containing the SSCP 

bits 8-47, implementation and installation dependent binary identification 
18 TS Usage 

bits 0-l, reserved 

bits 2-7, secondary CPMGR receive window size (0 means no pacing of requests flowing 

to the secondary) 

19-n Control vector, as described tn the section "Control Vectors" on page E-49 

Note: The following vector keys may be used in RSP(ACTCDRM): 

X'06' CDRM control vector 

X'09' Activation Request/Response Sequence Identifier control vector 

X'13' Gateway Support Capabilities control vector 

X'18' SSCP Name control vector 

X'FE' one or more control vector Keys not recognized in the corresponding request 


RSP(ACTPU); PU-->SSCP|PUCP, Exp; SC 


0 X'1ll" request code 
l bits 0-1, reserved 
bits 2-3, format of response: 
00 format 0 
01 format 1 


10 format 2 (this format requires that bits 4-7 be set to X'3') 
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11 format 3 (only for PU_T4/5s) 
bits 4-7, type activation selected: 
X'1' cold, IPL not required 


X'2' ERP 
X'3' cold, IPL required 
2-9 Contents ID: eight-character EBCDIC symbolic name of the load module currently oper- 


ating in the node; eight space (X'40') characters is the default value 
Note: End of Format 03; Formats 1-3 continue below. 


10-n Format I Continues 
10-11 Reserved 
l2-n Control vector as described in the section "Control Vectors" on page E-49 


Note: The following control vectors may be used in RSPCACTPU): 
X'07' PU FMD-RU-Usage control vector 

X'24' IPL Load Module Request control vector 

X'FE' vector key not recognized in the corresponding request 


10-n Format 2 Continues 
10-17 Load module ID: an .eight-character EBCDIC symbolic name of the requested IPL load 
module: 


X'4040...40' any load module will be accepted 
7=X'4040...40' identifies specific load module name 
18-19 Reserved 
20-n Control vector as dcecribed in the section "Control Vectors" on page E-49 
Note: The following control vectors may be used in RSP(ACTPU): 
X'07' PU FMD-RU-Usage 
X'FE' vector key not recognized in the corresponding request 
10-n Format 3 Continues 
10-n Control vector as described in the section "Control Vectors" on page E-49 
Note: The following control vectors may be used in RSP(ACTPU): 
X'09' Activation Request/Response Sequence Identifier control vector 
X'0B' SSCP-PU Session Capabilities control vector (this control vector is not included 
in RSPCACTPU) if all requested functions are supported as specified in the 
received X'0B' control vector (see X'0B' control vector)) 
X'FE' one or more vector keys not recognized in the corresponding request 


~ RSPC(BIND); SLU-->PLU, Exp; SC 


0 X'31' request code 

Note: The following bytes are returned for the extended nonnegotiable BIND response or for the 
negotiable BIND response. (The request code alone is sent if a nonnegotiable BIND request spec- 
ifies no session-level cryptography. ) 


1 bits 0-3, format: 0000 (only value defined) 
bits 4-7, type: 
0000 negotiable (only value defined for LU 6.2) 
0001 nonnegotiable 
2-25 Bytes as received on BIND request, for nonnegotiable response; or bytes having the 
same format, but possibly with values changed from those received on the BIND request, 
for negotiable response 


26-k Cryptography Options (see Note 4) 
26 bits 0-1, private cryptography options: for a nonnegotiable response, same value 


returned as received in the request, if present 
bits 2-3, session-level cryptography options: for a nonnegotiable response and an LU 
6.2 response, same value returned as received in the request, if present 
bits 4-7, session-level cryptography options field length: same value returned as 
received in the request, if present (Bytes 27-k are omitted if this length 
field is omitted or set to 0.) 
27 bits 0-1, session cryptography key encipherment ‘method: same value returned as 
received in the request, if present 
bits 2-4, reserved 
bits 5-7, cryptography cipher method: same value returned as received in the request, 
if present 
28-k An eight-byte implementation-chosen, nonzero, pseudo random session-seed cryptography 
value enciphered under the session cryptography key, if session-level cryptography is 
specified; otherwise, omitted 
k+l-r Bytes as received on BIND request, for nonnegotiable response; or bytes having the 
same format, but possibly with values changed from those received on the BIND request, 
for negotiable response 


Note 1: The extended format is required for the negotiable BIND response or if session-level 


cryptography is specified in the BIND request; otherwise, only the short form (request code) is 
used. 
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Note 2: On a response, if the last byte of a response without control vectors (byte 7, bit 6 = 
0} is a length field and that field is 0, that byte may be omitted from the response. This 
applies also to byte 26 (where the count occupies only bits 4-7) if bits 0-3 are also 0—the 
entire byte may be omitted if no bytes follow. 


Note 3: Reserved fields in the BIND are set by the SLU to binary 0's in the RSP(BIND); any 
fields at the end of the BIND that are not recognized by the SLU are discarded and not returned 
tn the RSP(BIND). 


Note 4: The Cryptography Options field is returned on the response for a nonnegotiable BIND and 
LU 6.2 BIND only when session-level cryptography was specified, or for a non-LU 6.2 negotiable 
BIND. 


RSP(CDINIT); SSCP-->SSCP, Norm; FMD NS(s) 


0-2 X'818641' NS header 

3 bits 0-3, format: same value as received in corresponding request 
bits 4-7, reserved 

G Procedure status: 


bits 0-3, reserved 
bits 4-7, status at SSCP receiving CDINIT: 
0000 reserved 
0001 initiate success ful—proceed 
0010 initiate success ful—aqueued 
0011 dequeued—success ful 
5-6 Retired 
7 LU status for LU associated with the SSCP receiving the CDINIT request: 
bit 0, reserved 
bit 1, 0 LU is unavailable 
1 LU is available 
bits 2-3, (reserved if LU is available) 
00 LU session limit exceeded 
01 reserved | 
10 LU is not currently able to comply with the PLU/SLU specification 
ll reserved 
bit 4, 0 existing SSCP to LU path 
1 no existing SSCP to LU path 
bit 5, (reserved in formats 0 and 1) 
0 UNBIND and SESSEND cannot be sent by the LU or by its boundary function Cif 
any ) . 3 
1 UNBIND and SESSEND will be sent by the LU or by its boundary function Cif 
any ) 
bits 6-7, 00 reserved 
01 LU is PLU 
10 LU is SLU 
1l reserved . 
Note: End of Formats 0, 1, and 43 Formats 2 and 3 continue below 


8 COS origin: 
bit 0, 0 no COS name from ILU 
1 COS name from ILU 
bits 1-2, (reserved if byte 8, bit 0 # 0) 
01 SSCP(DLU) chose COS name (DLU is SLU) 
10 SSCP(OLU) chose COS name (OLU is SLU) 
bits 3-7, reserved 

9-16 COS name (if byte 8, bit 0 = 0 and bits 1-2 # O1, this field carries unpredictable 
values and is not used): symbolic name of class of service in EBCDIC characters 
Note: For format 3 this COS name represents the COS name as Known in the network of 
the DLU. 

17-24 Mode name (if byte 8, bits 1-2 # 01, this field carries unpredictable values and is 
not used): an eight-byte symbolic name (implementation and installation dependent) 
that identifies the set of rules and protocols to be used for the session (included 
here for use in reactivating the (LU,LU) session, if necessary; see CINIT and SESSEND 
for other details) 
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Note: End of Format 23 Format 3 continues below. 


25-n One or more control vectors, as described in the section "Control Vectors" on page 

E-49 

Note: Vector key X'1A' is required for format 3; the other vectors are optional. If 

present, they appear in the order specified below. 

X'1A' NAU Address control vector (contains the DLU network address) 
Note: Between gateways, the DLU address is an address recognized in the 
subnetwork on the OLU side of the sending gateway. Within a gateway, the 
DLU address is an address recognized tn the network on the DLU side of the 
gateway node, until the SSCP with address alias responsibility 1s reached. 
This SSCP replaces the received address with an address recognized in the 
network on the OLU side of the gateway node. 


The network ID is identified in the X'19' vector for the DLU. 
X'14' Session Initiation control vector 
X'19' Resource Identifier control vector (for destination LU) 
X'19' Resource Identifier control vector (for origin LU) 


RSP(CDTERM); SSCP(DLU)-->SSCP(OLU), Norm; NS(s) 


0-2 X'818643' NS header 

3 bits 0-3, 0000 Format 0 (only value defined) 
bits 4-7, reserved 

4-6 Reserved 


RSP(CINIT); PLU-->SSCP, Norm; FMD NS(s) 

0-2 X'810601' NS header 

3-n Control vectors as described in the section "Control Vectors" on page E-49 
Note: The following control vector key is used in RSP(CINIT): 
X'FE' control vector keys not recognized 


RSP(DSRLST)3; SSCP-->SSCP, Norm; NS(s) 
0-2 X'818627' NS header : 
3-n Control list entry data for list type (See "Control Lists" on page E-57 for detailed 
descriptions) 
Note: One of the following control list entries 1s used: 
® When control list search argument is X'01' (LU Status List) 


3-n X'O1' LU Status List 
® When control list search argument is X'02' (Cross-Network LU Status List) 
3-n X'O1' LU Status List 
® When control list search argument is X'03' (Cross-Network SSCP List) 
3-n X'03' Cross-Network SSCP List 
RSPCINIT-OTHER-CD); SSCP-->SSCP, Norm; FMD NS(s) 
0-2 X'818640' NS header 
3 Format 


bits 0-3, 0000 Format 0 (only value defined) 
bits 4-7, reserved 
4 Procedure Status: 
bits 0-3, Status for SSCP(LUI1) 
0000 reserved 
0001 initiate success ful—proceed 
0010 initiate success ful—queued 
bits 4-7, Status for SSCP(LU2) 
0000 reserved 
0001 initiate success ful—proceed 
0010 initiate success ful—dqueued 
5 LUI Status 
bit 0,. reserved 
bit 1, 0 LUI is unavailable 
1 LUI is available 
bits 2-3, (reserved if LUI is available) 
00 LUI] session limit exceeded 
01 reserved 
10 LUL is not currently able to comply with the PLU/SLU specification 
ll reserved 
bits 4-5, reserved 
bits 6-7, 00 reserved 
01 LULL is PLU 
10 LUL is SLU 
11 reserved 
6 LU2 Status: 
bit 0, reserved 
bit 1, 0 LU2 is unavailable 
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1 LU2 is available 
bits 2-3, (reserved if LU2 is available) 
00 LU2 session limit exceeded 
01 reserved 
10 LU2 is not currently able to comply with the PLU/SLU specification 
ll reserved 
bits 4-5, reserved 
bits 6-7, 00 reserved 
01 LU2 1s PLU 
10 LU2 is SLU 
ll reserved 


RSP(RNAA); PU_T415-->SSCP, Norm; FMD NS(c) 


7-12 


13-18 


If ENA is not supported on this SSCP-to-PU_T4GI5 


session, the entire network address 1s in. each 
Element Address field throughout this RU. 


X'410210' NS header 
Set to same value as bytes 3-5 in RNAA request 
Number of element addresses returned 


® For assignment types X'00', X'OL', X'O02', X'11L', X'12', X'21l', X'22': 


Element address assigned: adjacent link station address for assignment type X'‘'00'; 
BF.LU element address for assignment types X'01', X'1l1', and X'21': LU address for 
assignment types X'02', X'1l2', and X'22' 
Any additional element addresses assigned (2-byte multiples), in the same format as 
bytes 7-83 the order of the element addresses returned corresponds to the order of the 
entries (bytes 7-n) in the RNAA request 


® For assignment type X'03': 


Destination-NAU alias address, applicable in the subnetwork adjacent to the PU, on the 
origin-NAU side of the PU 

Origin-NAU alias address, applicable in the subnetwork adjacent to the PU, on the 
destination-NAU side of the PU | 


RSP(ROUTE-TEST); PU_T415-->SSCP, Norm; FMD NS(ma) 


0-2 


X'410307' NS header 


Format: X'Ol' 

Number of Route Data fields 

Route Data: information about the ERs and VRs that were tested 

Virtual route identifier: 

bits 0-3, VRN of the VR tested 

bits 4-5, reserved 

bits 6-7, transmission priority field of the VR tested 

VR status: 

X'00' VR ts not defined 

X'O1' VR 1s in reset state 

X'02' activation of the VR is pending notification of the activation of the underlying 
ER 

X'03" an NC-ACTVR was sent to activate the VR,» but no RSP(NC-ACTVR) has been received 

X'04' an NC-ACTVR was received to activate the VR, but no RSP(NC-ACTVR) has been sent 

X'05' an NC-DACTVR(Orderly) has been sent, but no RSP(NC-DACTVR) has been received 

X'06' an NC-DACTVR(Orderly) was received, but no RSP(NC-DACTVR) has been sent 

X'07' an NC-DACTVR( Forced) was received, but no RSP(NC-DACTVR) has been sent 

X'08' an NC-DACTVR( Forced) was sent but no RSP(NC-DACTVR) has been received 

X'09' VR is active 

X'OA' retired 

bits 0-3, reserved 

bits 4-7, ERN of the ER tested 

ER status: 

X'00' ER is not defined and not currently operative 

X'Ol' ER is defined but not currently operative 

X'02' ER is defined and operative, but not currently active 

X'03' an NC-ER-ACT was sent, but no NC-ER-ACT-REPLY has been received 

X'04' an NC-ER-ACT was received, but no NC-ER-ACT-REPLY has been sent 

X'05' an NC-ER-ACT was received and an NC-ER-ACT-REPLY was sent; an NC-ER-ACT was 
sent, but no NC-ER-ACT-REPLY has been received 

X'06" an NC-ER-ACT was received but no ER is defined; should the ER subsequently 
become defined, am NC-ER-ACT will be sent 

X'07' an NC-ER-ACT was received and an NC-ER-ACT-REPLY was sent (no NC-ER-ACT has been 
sent from this end) 

X'08' ER is active and each node on the ER supports ER-VR protocols 

X'09' ER is operative but not currently defined 
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X'OA' ER is active and traverses a node that does not support ER-VR protocols 


9-12 Subarea address of the adjacent node through which the ER being tested flows from this 
node 

13 Transmission group number of the TG (to the node identified in bytes 9-12) over which 
the ER being tested flows from this node 

14 Reserved 

15-m Any additional 10-byte entries in the same format as bytes 5-14 


m+l-m+4  Subarea address at the route origin | 
Note: This is the subarea address of the sender in the address space as defined by 
the network ID contained in bytes m+5-m+12 

m+5-m+l2 Network ID of the subnetwork wherein the tested route resides (same as bytes 27-34 of 
corresponding ROUTE-TEST request) | 
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CONTROL VECTORS 


Control Vectors 


The following table shows, by key value, the control vector and the message-unit structures that 


can carry the control vector. 


Key Control Vector 


X'06' CDRM 

X'07' PU FMD-RU-Usage 

X'09' Activation Request/Response 
Sequence Identifier 

X'0B' SSCP-PU Session Capabilities 

X'0D' Mode / Class-of-Service / 
Virtual-Route-Identifier-List 

X'13' Gateway Support Capabilities 

X'14° Session Initiation 

X'15" Network-Qualified Address Pair 

X'16" Names Substitution 

X'17' SSCP Identifier 

X'18" SSCP Name 

X'19' Resource Identifier 

X'1A' NAU Address 

X'1B' VRID List 

X'1LE' VR-ER Mapping Data 

X'1F' ER Configuration 

X'23' Local-Form Session Identifier 

X'24' IPL Load Module Request 

X'FE' Control Vector Keys Not 
Recognized 


Applicable Message-Unit Structures 


ACTCDRM, RSP( ACTCDRM) 
RSP(ACTPU) 
ACTCDRM, ACTPU, RSP(ACTCDRM|ACTPU) 


ACTPU, RSPCACTPU) 
CINIT 


ACTCDRM, RSPCACTCDRM) 
CDINIT, RSP(CDINIT ) 

SETCV, NOTIFY(c), CINIT 
SETCV 

NOTIFY(s) 

ACTPU, ACTCDRM, RSPCACTCDRM) 
CDINIT, RSP(CDINIT), INIT-OTHER-CD, DSRLST, NOTIFY(s) 
SETCV, CDINIT, RSPC(CDINIT) 
SETCV, NOTIFY(c) 

NOTIFY(c), SESSST 
NC-ER-TEST-REPLY, ER-TESTED 
SESSST 

RSP(ACTPU) 

RSPCACTCDRM), RSPCACTPU), 
RSP(BIND), RSP(CINIT) 


Note: Control vector X'FE' is used to report receipt of one or more unrecognized control vec- 
tors. The receiver responds using a X'FE' control vector that identifies each unrecognized con- 
trol vector by key; this allows the response sender to indicate that some control vectors have 
been processed, while others have not. 


The control vectors are defined as follows (with zero-origin indexing of the vector bytes—see 
the individual RU description for the actual displacement within the RU): 

Note: When more than one control vector may appear in an RU, unless otherwise stated, the vec- 
tors may appear in any order. 


CDRM Control Vector 


0 Key: X'06° : 

1 Lengths in binary, of Vector Data field (X'00' = no Vector Data field present.) 
e-n Vector Data 

2 CDRM profile: X'00' (only value defined) 

3~-5(=n) CDRM usage: 


bit 0, 0 name pair (X'06') session Key supported 
l name pair session key not supported 
bit 1, 0 address pair (X'07) session key not supported 
1 address pair session key supported 
Note: If the control vector is omitted or the length is 0, the correspond- 
ing request or response implicitly specifies that the name pair (X'06') ses- 
sion key 1s supported and the others are not. 
bit 2, 0 parallel sessions not supported 
1 parallel sessions supported 
bit 3, 0 URC not supported by SSCP (and all PLUs within its domain) in cross-domain 
session initiation 
1 URC supported by SSCP (and all PLUs within its domain) in cross-domain ses- 
sion inittation 
bit 4, 0 CDINIT (TYPE=DQ) (Format 1 or 4) with Type field bits specifying “leave on 
queue if dequeue retry is unsuccessful" not supported 
1 CDINIT (TYPE=DQ) (Format 1 or 4) with Type field bits specifying “leave on 
queue 1f dequeue retry is unsuccessful" supported 
bit 5, 0 PCID (X'05') session key not supported 
1 PCID session key supported 
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bit 6, 0 CDSESSEND from SSCP(SLU) and CDINIT(Format 2) not supported; requires 
NS-LSA (see SNA Reference Summary) to reset session Knowledge; therefore, 
all sessions managed by the SSCP use virtual routes mapping to ERO from the 
subarea of the SLU to the subarea of the PLU 

1 CDSESSEND from SSCP(SLU) and CDINIT(Format 2) supported; NS-LSA is not used 

to reset session Knowledge; therefore, no ER restrictions exist for sessions 
managed by this SSCP 

bit 7, reserved 

bit 8, 0 SSCP does not support the PLU capability indicator in LU Status (X'01') Con- 

trol List 

SSCP supports the PLU capability indicator in LU Status (X'01') Control List 

network-qualified address pair (X'15') session key not supported 

network-qualified address pair session Key supported 

INIT-OTHER-CD Format 2 not supported 

INIT-OTHER-CD Format 2 supported 

INIT-OTHER-CD Format 3 not supported 

INIT-OTHER-CD Format 3 supported 

Format 3 and 4 of CDINIT not supported 

Format 3 and 4 CDINIT supported: includes NAU Address (X'1A') control vec- 

tor 

Note: If control vector X'13' is also included in this ACTCDRM request or 

response, CDINIT format 3 or 4 may include additional control vectors for 

cross-network session setup 

bit 13, 0 Format 1 of CDCINIT not supported: includes Network-Qualified Address Pair 
(X'15') session key 


bit 10, 


bit 12> 


M-OKM OF OF OC 


1 Format 1 CDCINIT supported 
bit 14, 0 NOTIFY NS(s) key X'06' not useeeted 
1 NOTIFY NS(s) key X'06' supported 
bit 15, 0 notification of lost session (LU-LU) awareness not supported 
1 notification of lost session (LU-LU) awareness supported (The SSCP sends 


CDSESSEND if it has lost awareness of the session identified by the Session 
Key Content field in the CDSESSEND. ) 
bit 16, Support of CDINIT request for notification of DLU availability: 
O CDINIT (byte 20 bits 6-7) request for noti fication of DLU availability not 
supported | 
1 CDINIT (byte 20 bits 6-7) request for notification of DLU availability sup- 
ported. NOTIFY NS(s) key X'07' with session Key X'01" or NOTIFY NS(s) key 
X'08' is sent. 
bit 17, 0 backup session request is not supported in CDINIT 
1 backup session request is supported in CDINIT 
bit 18, ENA support: 
ENA not supported 
ENA supported 
network-qualified names support indicator in CDINIT and RSP(CDINIT) not sup- 
ported 
1 network-qualified names support indicator in CDINIT and RSP(CDINIT) sup- 
ported; this implies that the sending SSCP supports sending and receiving 
2 fully-qualified PCID on the CDRM session 
Note: This vector is sent on ACTCDORM and RSP(ACTCDRM) to define the receive capabilities of the 
SSCP building the request or response. An SSCP reports all its capabilities. If an SSCP does 
not report support of a particular function, its session partner SSCP is responsible for not 
invoking that function. An SSCP receiving the vector in an ACTCDRM request or response ignores 
bits within the usage indicators that it does not understand. In its own vector, the SSCP sets 
such bits to 0, indicating that it does not support the function. 


ome 


bit 19, 


PU FMD-RU-Usage Control Vector 
0 Key: xX'07' 
1 bits 0-5, reserved. 
bit 6, adjacent PU load capability Cinitialized to 0 by the PU_T2): 
0 adjacent PU cannot load the PU_T2 node 
1 adjacent PU can load the PU_T2 node (set by the boundary function in the 
adjacent subarea node) 
bit 7, FMD request capability of the node: 
0 PU cannot receive FMD requests from the SSCP 
1 PU can receive FMD requests from the SSCP 
2-7 Reserved 


Activation Request/Response Sequence Identifier Control Vector 


0. Key: xX'09' 
1 Length, in binary, of Vector Data field 
2-n Vector Data 


2-9(=n) Activation request/response sequence identifier: an eight-byte binary value, gener- 
ated by the sender of ACTCDRM, RSP(ACTCDRM), ACTPU, and echoed in RSP(ACTPU), and used 
by the receiver to determine whether the current RU supersedes a previously received 
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RU from the same sender (If the current RU has an activation request/response 
sequence identifier value greater than the corresponding activation request/response 
sequence identifier value of the earlier ACTPU, ACTCDRM, or RSP(ACTCDRM), the current 
RU is accepted and processed, while the earlier RU is superseded. The eight-byte 
field has the following characteristic: If nl was generated at time tl, and n2 was 
generated at time t2, and tl < t2, then nl < n2.) 


SSCP-PU Session Capabilities Control Vector 


NN & & 
{ 
> 


Note: 


Key: X'OB' 
Length, in binary, of Vector Data field 


Vector Data 


bit 0, lost subarea requirement: 
0 NS-LSA (see SNA Reference Summary) required 
1 NS-LSA not required 
bit 1, ALS station support: 
0 adjacent link station network address not supported 
1 adjacent link station network address supported 
bit 2, gateway support: 
0 no gateway support 
1 this component supports gateway function 
bit 3, notification of other-network lost route: 
0 do not notify the SSCP (via ROUTE-INOP or ER-TESTED) of an inoperative route 
in subnetworks other than this SSCP's | 
1 notify the SSCP (via ROUTE-INOP or ER-TESTED format 2) of an inoperative 
route in subnetworks other than this SSCP's 
bit 4), notification of same-network lost route: 
0 do not send ROUTE-INOP; send ER-TESTED format 1 for routes in the sender's 
subnetwork 
1 send ROUTE-INOP if a VR or ER is lost in this SSCP's own subnetwork; send 
ER-TESTED format 2 
Note: An SSCP always receives ER-TESTED for routes in the SSCP's own subnet- 
work; additionally, this bit indicates whether ROUTE-INOP may flow for lost 
ERs or VRs tn the SSCP's own subnetwork. 
bit 5, CONTACTED( Loaded) format: 
0 send CONTACTED (X'04') 
1 send CONTACTED (X'09') 


bit 6, ENA support: 


0 ENA is not supported 
1 ENA is supported 
bit 7, reserved 


This control vector is not sent on RSP(ACTPU) if the PU is willing and able to operate at 


the capabilities level requested by the sending SSCP. If the PU is not capable of the requested 
support, the bits are turned off that are not supported and the control vector is returned to 
the SSCP as X'0B' control vector in RSPCACTPU). 


Mode/COS/VRID List Control Vector 


21 
2e-n 


Key: X'0OD' 

Length, in binary, of Vector Data field 

Vector Data 

Mode name: an eight-character symbolic name (implementation and installation depend- 

ent) of type-A symbol string characters that identifies the set of rules and protocols 

to be used for the session; used by the SSCP(SLU) to select the BIND image that will 

be used by the SSCP(PLU) to build the CINIT request 

COS name: symbolic name of class of service in EBCDIC characters 

Virtual Route Information 

Length (Cin bytes )—including format, type, number of entries, and entries of Virtual 

Route Information field 

Format of virtual route identifier List: 

X'00’ format 0 (only value defined) 

Type of virtual route required: 

X'00' only virtual routes mapping to ERO from the subarea of the SLU to the subarea of 
the PLU may be used 

X'O01' virtual routes mapping to any ERN may be used 

Number of entries in the virtual route identifier list 

Virtual route identifier list: two-byte (VRN, TPF) entries where VRN is one byte and 

TPF is one byte . 


Network Name Control Vector 


Key: X'OE' 
Length, in binary, of Vector Data field 


Vector Data 


Network name type: 
Network-qualified name: a 1l- to 17-byte name consisting of an optional qualifier con- 
catenated to a 1l- to 8-byte name; when present, the qualifier contains a l1- to 8-byte 
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E-52 


network identifier concatenated with a period (when the qualifier is not present, the 
period is omitted). The network-qualified name appears as follows: NETID.NAME, with 
no imbedded blanks and with optional but not significant trailing blanks. 


Gateway Support Capabilities Control Vector 


0 Key: X'13' 

l Length, in binary, of Vector Data field 

2-m Vector Data 

2-m A pair of session Keys as described in the section "Session Keys" on page E-58 


Note: These session keys appear in the following order: 

X'15' network-qualified address pair (NAU 1 and NAU 2 define the sender's address and 
the destination address, respectively, as Known in the network of the sender. ) 

X'15' network-qualified address pair (NAU 1 and NAU 2 define the origin address and 
the destination address, respectively, as Known in the network adjacent to the 
sender. ) 


Session Initiation Control Vector 


0 Key: X'14' 

1 Length» in binary, of Vector Data field 

2-n Vector Data | 

2-9 Network ID 1: For CDINIT this is the network ID of the subnetwork containing the DLU. 
For RSP(CDINIT) this is the network ID of the subnetwork on the DLU side of the gate- 
way node. 
Note: Network ID 1 and COS name 1 fields are reserved in CDINIT if COS name not 
received from the ILU or if Control Vector X'19' for the DLU indicates that the trans- 
lation of alias to real DLU name has not occurred. 

10-17 COS name 1: For CDINIT and RSP(COINIT), this is the COS name as Known in the above 
network. 

18-25 Network ID 2: This field and the subsequent COS name 2 field are used in conjunction 


with the network ID 1 and COS name 1 fields to distribute the COS name as Known on 
both sides of the gateway node to the gateway SSCP responsible for COS name to VRID 
resolution in the shared control gateway environment. Network ID 2 identifies the 
subnetwork on the OLU side of the gateway node. 

Note: Network ID 2 is reserved for CDINIT or when RSP(CDINIT) is flowing from one 
gateway to another and if COS name translation has not yet occurred in this gateway 
for RSP(CDINIT). 

26-33 COS name 2: For RSP(CDINIT), this is the COS name as Known in the above network. 
Note: COS name 2 is reserved for CDINIT or when RSP(CDINIT) is flowing from one. gate- 
way to another and if COS name translation has not yet occurred in this gateway for 
RSP(CDINIT). 

34 Usage indicators: 
bit 0, parallel session capabilities of adjacent SSCP on the OLU side of the gateway 

node: 

0 parallel sessions not supported 

1 parallel sessions supported 

Note: This bit 1s set by the first gateway SSCP on each gateway for CDINIT 

and is reserved for RSP(CDINIT). | 

bit 1, configuration information: | 

0 The RU sender and receiver are not in the same gateway (i.e., the gateway 
that is to be used by the intended cross-network LU-LU session) 

1 The RU sender and receiver are in the same gateway (The gateway reference is 
relative to the cross-network LU-LU session, not the cross-network SSCP-SSCP 
session between the RU sender and receiver. ) 

Note: Network ID 2, COS name 2, and the second instance of session key X'15' 

are reserved tn CDINIT and RSP(CDINIT) flowing from one gateway to another 

(when bit 1 = 0). 7 | 

bit 2, address aliasing support (reserved when byte 34, bit 1 is 0): 

0 sender is not designated for address aliasing support 

1 sender is designated for address aliasing support 

Note: This bit is used to signal whether the sender is the predesignated 

gateway SSCP for address aliasing support of the gateway node specified in 

bytes 43-46. 

bits 3-7, reserved 


35-42 Mode name as Known in the destination network 
Note: The mode name as Known in the network of the OLU is contained in bytes 21-28 of 
CDINIT. : 

43-46 Subarea address of the gateway PU that is to be used for the intended LU-LU session 
(reserved when byte 34, bit 1 is 0) 

47-54 Network ID of the subnetwork in which the above subarea address is valid (reserved 
when byte 34, bit 1 is 0) 

55-n A pair of session Keys as described in the section "Session Keys" on page E-58 


Note: The following session keys are used: | 
X'15' network-qualified address pair (session key 1): OLU and DLU respectively 
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Between gateways, usage is as follows: 


e CDINIT: address pair on the OLU side of the gateway when received, on the 
DLU side of the gateway when sent. The DLU address is reserved. 


® RSP(CDINIT): address pair on the DLU side of the gateway when received, on 
the OLU side of the gateway when sent. 


Within a gateway, usage is as follows: 


e CDINIT: address pair on the DLU side of the gateway; if the SSCP with alias 
address responsibility has not been reached, session key 1 is reserved 
(i.e., it is present with a length of 0, or present with nonzero length and 
contents of 0's). Otherwise, only the DLU portion of the address pair is 
reserved. 


e RSP(CDINIT): address pair on the OLU side of the gatenay. 


Note: Session key 1 is used both between gateways (byte 34, bit 1 = 0) and 
within a gateway (byte 34, bit 1 = 1). 
X'15' network-qualified address pair (session key 2): OLU and DLU respectively 


Between gateways, session key 2 is reserved (as described above). 
Within a gateway, usage is as follows: 


® CDINIT: address pair on the OLU side of the gateway; upon entry into a 
gateway, session key 1 in the input CDINIT 1s copied into session key 2 of 
the output CDINIT. The DLU address is reserved until the SSCP with alias 
address responsibility 1s reached. 


e RSP(CDINIT): address pair on the DLU side of the gateway; upon entry into a 
gateway, session key 1 in the input RSP(CDINIT) 1s copied into session key 2 
of the output RSP(CDINIT). 


Note: Session key 2 is used only within a gateway; otherwise, it is reserved 
(1.e., it 1s present with a length of 0, or present with nonzero length and con- 
tents of 0's). 


Network-Qualified Address Pair Control Vector 


0 

I 
e-n 
2-7 
8-13 


14-21(=n) 


Key: X'15' 

Length, in binary, of Vector Data field 

Vector Data 

NAU 1 network address 

NAU 2 network address 

Note: See the RUs that carry this vector for NAUI1/NAU2 definitions and order require- 
ments. 

Network ID of the subnetwork in which the. above addresses are valid 

Note: If the Network ID field contains all space (X'40...40') characters, the network 
addresses are in the sender's network. 


Names Substitution Control Vector 


0 

1 

2-n 

Z 

3-m 
m+] 
m+2-n 


Key: X'16' 

Length, in binary, of the Vector Data field 
Vector Data 

Length of PLU alias name 

PLU alias name 

Length of SLU real name 

SLU real name 


Note: The Network-Qualified Address Pair control vector always accompanies this vector in 


SETCV. 


SSCP Identifier Control Vector 


Key: X'17' 
Length, in binary, of the Vector Data field 
Vector Data 
SSCP visit count (set by the first gateway SSCP and then decremented at each gateway 
SSCP on the path) 
Note: This field is ignored by the receiver if byte 3, bit 1 is 0. 
Usage indicators: 
bit 0, reserved 
bit 1, target resource indicator: 
0 the resource named in this vector is not the target resource 
1 the resource named in this vector is the target resource 
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4G 
5-m 
m+1 
mt2-n 


SSCP Name 
0 

i 

2-n 

2-9 
10-17(=n) 


bits 2-7, reserved 

Length of network ID 

Network ID of the subnetwork containing the SSCP 
Length of SSCP name 

Name of the SSCP 


Control Vector 

Key: X'18' 

Length, in binary, of the Vector Data field 
Vector Data 

Name of SSCP: symbolic name in EBCDIC characters 
Network ID of the subnetwork containing the SSCP 


Resource Identifier Control Vector 


Mm ~M & Oo 
t 
be 3 


4 

5-m 
m+ 1 
m+t2-n 
n+1 
n+2-p 
ptl 
pte-q 
qtl 
qte-r 


Key: X'19' 
Length, in binary, of the Vector Data field 
Vector Data 
SSCP visit count (set by the first gateway SSCP and then decremented at each gateway 
SSCP on the path) 
Note: This field 1s ignored by the receiver if byte 3, bit 1 is 0. 
Usage indicators: 
bit 0, name translation: 
0 translation has not occurred for this name 
1 translation has occurred for this name 
bit 1, target resource indicator: 
0 the resource named in this vector is not the target resource 
1 the resource named in this vector is the target resource 
bits 2-7, reserved 
Length of SSCP name 
Name of SSCP that controls the LU: symbolic name in EBCDIC characters 
Length of network ID 
Network ID of the subnetwork containing the LU 
Length of LU name 
Network name of the LU (real name) 
Length of network ID 
Network ID of the subnetwork in which the LU name alias is Known 
Length of LU name 
Alias LU name 


NAU Address Control Vector 


12 
13-n 


Key: X'lA' 
Length, in binary, of the Vector Data field 


Vector Data 


Network address of the NAU 

ENA support: 

bit 0, 0 NAU does not support ENA 
1 NAU supports ENA 

bits 1-7, reserved 


Control Vector 
Key: X'1B' 
Length, in binary, of Vector Data field 


Vector Data 


Network ID 

Virtual Route Information Field 

Format of virtual route list: 

X'00' format 0 (only value defined) 

Type of virtual route required: 

X'00' only virtual routes mapping to ERO from the subarea of the SLU to the subarea of 
the PLU may be used 

X'O1' virtual routes mapping to any ERN may be used 

Number of entries in the Virtual Route Information field: 

Virtual route list: two-byte (VRN, TPF) entries, where VRN ts one byte and TPF is one © 

byte 2 


VR-ER Mapping Data Control Vector 


e-n 


Key: X'‘'IE' 

Length, in binary, of Vector Data field 

Vector Data 

VRN and TPF data: 

bits 0-3, virtual route number (VRN) assigned to the session indicated in the contains 
ing RU 

bits 4-5, reserved | 
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4(=n) 


bits 6-7, Transmission Priority field (TPF) assigned to the session indicated in the 
containing RU 

Explicit route data: 

bits 0-3, reserved 

bits 4-7, outbound ERN for the VRN specified in byte 2, bits 0-3 

Reverse explicit route data: 

bits 0-3, reserved 

bits 4-7, RERN corresponding to the ERN in byte 3 


ER Configuration Control Vector 


0 
1 
e-p 
2 
3 
4-7 


8 
9-m 


m+] 


mt2-n 
ntl-p 


Key: X'1F' 

Length, in binary, of Vector Data field 

Vector Data 

Outbound TG number (reserved in last vector) 

Inbound TG number (reserved in first vector) 

Subarea address of the PU that has appended this control vector, in the network in 
which the containing RU is flowing 

Number of SSCP Address fields in bytes 9-m 

SSCP address fields: list of 8-byte fields, one for each SSCP that currently controls 
at least one active link in any TG underlying the tested ER or has an active SSCP-PU 
session 


Note: The format of each 8-byte field is (shown zero-origin): 

Reserved 

bits 0-5, reserved 

bit 6, set to 1 if this SSCP has at least one link active in the TG over which the ER 
test will be sent, as specified in the Outbound TG Number field (byte 2 of 
this control vector) 

bit 7, set to 1 if this SSCP has at least one link active in the TG over which the ER 
test was received, as specified in the Inbound TG Number field (byte 3 of this 
control vector) 

Note: If bits 6 and 7 are both 0, the address in bytes 2 through 7 is the address of 

an SSCP that did not issue an ACTLINK for any link in either the inbound or outbound 

T. In this case, it is an SSCP that has an SSCP-PU session with this node. 

Address of the SSCP | 

Note: End of the 8-byte field format 


Length, in binary, of network ID 

Note: When the length is 0, the network ID is the same as that of the sub-network 
containing the ER, and the fields defined in bytes m+#2-p are not included. 

Network ID of the network in which the SSCP addresses are Known 

Four byte Subarea address of the PU that has appended this control vector, as Known tn 
the network defined in bytes m+2-n 


Local Form Session Identifier Control Vector 


0 
1 
2-p 


3-p 
3(=p) 


Key: X'23' 

Length, in binary, of Vector Data field 
Vector Data 

Format: 

X'02' Format 2: FID 2 session identifier 
X'03' Format 3: FID 3 session identifier 


For format 2-——-FID 2 

Session identifier (SID) for Format 2—FID 2 

SID High (SIDH): OAF' from the TH of the BIND request 
SID Low (SIDL): DAF‘ from the TH of the BIND request 
Flags: 

bits 0-5, reserved 


bit 6, ODAI field from TH of the BIND request 


bit 7, reserved 


For format 3-—FID 3 
Session identifier for Format 3-——FID 3 
LSID from TH of the BIND request 


IPL Load Module Request Control Vector 


Key: X'24' 

Length, in binary, of Vector Data field 

Vector Data | 

Load module ID: an eight-character type-A symbol string symbolic name of the 
requested IPL load module: 

X'4040...40' any load module will be accepted 


~“X'G040...40' identifies specific load module name 
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Control Vector Keys Not Recognized Control Vector 


0 Key: X'FE' 
1 Length, in binary, of Vector Data field 
e-n Vector data: one or more one-byte control vector key values that were not recognized 


in the corresponding request 
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Control Lists 


CONTROL LISTS 


The following table shows, by list type, the control lists and the message structures that can 
carry the control list. 


Type Control List Applicable Message-Unit Structures 
X'O1' LU Status +RSP(DSRLST ) 
X'03' Other-Network SSCP +RSP(DSRLST ) 


The control lists are defined, by type, as follows (with zero-origin indexing of the list bytes; 
see the individual RU description for the actual displacement within the RU): 

Note: Control List data is requested by type; however, the type 1s not included in the reply RU 
that carries the request control list. 


LU Status Control List 
® Type: xX'Ol' 
0 LU status 
bit 0, reserved 
bit 1, 0 LU is unavailable 
1 LU is available 
bits 2-3, (if LU is unavailable) 
00 LU session count exceeded 
01 LU is being taken down (not accepting new sessions ) 
10 LU is not currently able to comply with the PLU specification 
1l reserved 
bit 4, 0 existing SSCP to LU path 
1 no existing SSCP to LU path 
bits 5-7, reserved 
| LU information: 
bit 0, 0 LU does not reside in a PU_T5 node 
1 LU resides in a PU_T5 node 
bit 1, PLU capability 
0 LU capability of acting as PLU not determined 
1 LU is capable of acting as PLU (capability may be disabled now and thus the 
session will be queued) 
bits 2-6, reserved 
bit 7, 0 LU is accepting INITIATEs/logons 
1 LU is temporarily not accepting INITIATEs/logons 
2-3 Session count (range: 0-65535) 


Other-Network SSCP Control List 
® Type: X'Q3' 
0 Capability byte: 
bit 0, parallel (LU-LU) session capability of the SSCP to which the gateway SSCP on 
the DLU side of the gateway node will forward CDINIT: 
0 SSCP does not have parallel session capability 
1 SSCP has parallel session capability 
bit 1, ENA support 
0 DLU does not support ENA 
1 DLU supports ENA 
bits 2-7, reserved | 
1-8 Network ID of the adjacent subnetwork 
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Session Keys 


SESSION KEYS 


The following table shows, by key value, the session Key and the message-unit structures that 
can carry the session key. 


Key Session Key Applicable Message-Unit Structures 

X'O1' Uninterpreted name TERM-SELF 

X'O1' Network name NOTIFY(s) 

X05 PCID CDTERM and NOTIFY 

X'06' Uninterpreted name pair CLEANUP and TERM-OTHER 

X'06' Network name pair CDSESSEND, CDSESSSF, CDSESSST, CDSESSTF, CDTERM, NOTIFY, 


and SESSEND 


X'07' Network address pair | BINDF, CDSESSEND, CDSESSSF, CDSESSST, CDSESSTF, CDTERM, 
CINIT, CLEANUP, CTERM, NOTIFY, SESSEND, SESSST, 
TERM-OTHER, TERM-SELF, and UNBINDF 


X'OA' URC NOTIFY, TERM-OTHER, and TERM-SELF 
X'15' Network-Qualified address pair BINDF, CDCINIT, CDINIT, CDSESSEND, CDSESSSF, CDSESSST, 
CDSESSTF, CDTERM, CLEANUP, CTERM, NOTIFY, REQACTCDRM, 


SESSEND, SESSST, TERM-OTHER, TERM-SELF, UNBINDF, and 
Control Vectors X'13' and X'14' 


The session Keys are defined as follows (with zero-origin indexing of the key bytes—see the 
individual RU description for the actual displacement within the RU. 


Network or Uninterpreted Name Session Key 


0 Key: X'OL' 

1 Type: X'F3' logical unit 

2 Length, in binary» of name 
3-n Network or Uninterpreted Name 


Note: For a Network Name session key, the name is a symbolic name; for an Uninter- 
preted Name session key, the name is any EBCDIC character string. 


PCID Session Key 


0 Key: X'05' 
1-2 Network address of the SSCP generating this PCID 
3-8 A unique 6-byte value, generated by the SSCP initiating the cross-domain procedure, 


that is retained and used in all cross-domain requests dealing with the same procedure 
until it is completed 


Network Name Pair or Uninterpreted Name Pair Session Key 


0 Key: X'06' 

1 Type: X'F3' logical unit 

2 Length, in binary, of PLU (or OLU or LUI) name 
3-m Name in EBCDIC characters (see Note below) 

m+l Type: X'F3' logical unit 

m+2 Length, in binary, of SLU (or DLU or LU2) name 
m+3-n Name in EBCDIC characters (see Note below) 


Note: For a Network Name Pair session key, the names consist of type-A symbol-string charac- 
ters; for an Uninterpreted Name Pair session key, the names are any EBCDIC strings. 


Network Address Pair Session Key 


0 Key: X'07' 

1-2 Network address of NAU1 

3-4 Network address of NAU2 
Note: See the RUs that carry this session key for NAUL/NAU2 definitions and order 
requirements. 


URC Session Key 


0 Key: X'OA' 
1 Length, in binary, of the URC 
2-n URC: LU-defined identifier 


Network-Qualified Address Pair Session Key 
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Session Keys 


Key: X'15' 

Length, in binary, of Key Data field 

KEY Data field 

NAUI] network address 

NAU2 network address 

Note: See the RUs that carry this session key for NAUI/NAU2 definitions and order 
requirements. 

Network ID of the subnetwork in which the above addresses are valid 

Note: The Length byte is set to 12 when network ID is not included and to 20 when 
network ID is included. If the Network ID contains all space (X'40...40') characters, 
the network addresses are in the sender's network. 
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APPENDIX G. SENSE DATA 


‘eaten 


The sense data included with an EXCEPTION REQUEST (EXR), a negative response, an UNBIND request, 
a function management header type 7 (FMH-7), or a send or receive check 1s a four-byte field 
(see Figure G-1) that generally includes a one-byte category value, a one-byte modifier value, 
and two bytes of sense code specific information, whose format is defined along with the sense 
code definition, below. 


Byte 0 I 2 3 


Category Modifier Sense code specific 
information 


Sense Code 


| <——————_—_—_————— Sense Data —————_—__—_—_———» 


Figure G-1. Sense Data Format 


Together, the category byte 0, the modifier byte 1, and the sense code specific bytes 2 and 3 
hold the sense data defined for the exception condition that has occurred. 


The following categories are defined; all others are reserved: 


VALUE CATEGORY 

X'00' User Sense Data Only 

X'08' Request Reject 

X'10° Request Error 

X'20' State Error 

X'40' Request Header (RH) Usage Error 
X'80' Path Error 


The category User Sense Data Only (X'00') allows the end users to exchange sense data in bytes 
2-3 for conditions not defined by SNA within the other categories (and perhaps unique to the end 
users involved). The modifier value is also X'00'. In earlier versions of SNA, user data (as 
well as implementation-specific data) generally could be carried in bytes 2-3 for all catego- 
ries. This is no longer permitted. Bytes 2-3 are used only for SNA-defined conditions for non- 
zero categories. 


The sense codes for the other categories are discussed below. 


ENCARTA «RINE ETD OUPURENESIDSRRGTROROCITEED 


This category indicates that the request was delivered to the intended component and was under- 
stood and supported, but not executed. 


Category and modifier (in hexadecimal): 


0801 Resource Not Available: The LU, PU, or link specified in an RU is not available. 
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G-2 


0802 


0803 


0804 


0805 


0806 


0807 


0808 


0809 


Intervention Required: Forms or cards are required at an output device, or a device is 
temporarily in local mode, or other conditions require intervention. 


Missing Password: The required password was not supplied. 


Invalid Password: Password was not valid. 


Session Limit Exceeded: The requested session cannot be activated, as one of the NAUs 
is at its session limit (e.g., LU-LU session Limit, or [LU, model session limit). 
Applies to ACTCDRM, INIT, BIND, and CINIT requests. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 No specific code applies. 


0001 If accepted, the BIND request would prevent either the receiving LU or the send- 
ing LU from activating the number of contention winner sessions to the partner 
LU that were agreed upon during a change-number-of-sessions procedure. 


Resource Unknown: The request contained a name or address not identifying a PU, LU, 
link, or link station Known to the receiver. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 


0001 The resources identified in a subvector carrying an address list are unknown to 
the receiver. 


Note: When this sense data flows in a -RSP to an NMVT, the referenced subvector car- 
rying an address list is the one that was present in the request NMVT to which the 
-RSP corresponds. When this sense data flows in a Sense Data (X'7D') MS common sub- 
vector, the referenced subvector is present with the X'7D' subvector in the same major 
vector. 


Note: In an interconnected network environment, this sense code may be set by an SSCP 
in whose subnetwork and domain the LU was expected to reside; it is not set by an SSCP 
that is only an intermediary on the session-setup path. <A gateway SSCP examines the 
Resource Identifier control vector in a session setup request (e.g., CDINIT);, to 
determine whether the LU is in the SSCP's subnetwork and domain. 


Resource Not Available--LUSTAT Forthcoming: A subsidiary device will be unavailable 
for an indeterminate period of time. LUSTAT will be sent when the device becomes 
available. 


Invalid Contents ID: The contents ID contained on the ACTCDRM request was found to be 


invalid. 


Mode Inconsistency: The requested function cannot be performed in the present state 
of the receiver. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 
001C The RNAA request contains a network ID that is not Known to the gateway PU. 


001D An address pair session Key in a Network-Qualified Address Pair control vector 
(X'15') is not Known to the gateway PU. 


COlE A gateway PU received an RNAA request for a cross-network session and all possi- 
ble address transforms for the named resource are allocated. 


OOl1F An SSCP has detected a specification of gateway responsibility in the CDINIT 
request that 1s not consistent with tts own definition. For example, an SSCP 
that has predesignated responsibility to control a gateway node specified in the 
CDINIT request sends this sense data when it receives the CDINIT from a session 
partner and the CDINIT indicates that the session partner also has predesignated 
responsibility for the gateway node; in this situation, a mismatch exists in the 
responsibilities of the SSCPs, because both cannot simultaneously have predesig- 
nated responsibility for the gateway node. | 
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080A 


080B 


0s0oc 


080D 


O80E 


O80F 


0810 


0811 


08le 


0020 The gateway node receiving an RNAA request cannot support another session 
between the named resource pair. 


0024 A PU received an ACTPU request with the SSCP-PU Session Capabilities control 
vector (X'0B') indicating that the sending SSCP does not support ENA, but the PU 
does not Know the SSCP's maximum subarea address value. 


0027 A request for a function was received by a component but the function was not 
enabled/activated. 


Permission Rejected: The receiver has denied an implicit or explicit request of the 
sender; when sent in response to BIND, it implies either that the secondary LU will 
not notify the SSCP when a BIND can be accepted, or that the SSCP does not recognize 
the NOTIFY vector key X'0C'. (See the X'0845' sense code for a contrasting response. ) 


Bracket Race Error: Loss of contention within the bracket protocol. This error can 
arise when bracket initiation/termination by both NAUs is allowed 


Procedure Not Supported: A procedure (Test, Trace, IPL, REQMS type, MS major vector 
key) specified in an RU its not supported by the receiver. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 
0005 The MS major vector key is not supported by the receiver. 


0006 The MS major vector is identified as one that contains a command, but the 
receiver does not recognize or support the command subvector. (See the X'086C' 
sense code for the case in which the command subvector is identified, but an 
additional required subvector is missing. ) 


0007 A request for a function is supported by the receiver, but the resource identi- 
fied in the request does not support that function (no function is specifically 
indicated). 


000A A request was received containing an address list MS subvector with multiple 
entries, but the receiver supports only a single entry in such a subvector. 


NAU Contention: A request to activate a session was received while the receiving 
half-session was awaiting a response to a previously sent activation request for the 
same seS5510n3; e.g.» the SSCP receives an ACTCDRM from the other SSCP before it 
receives the response for an ACTCDRM that it sent to the other SSCP and the SSCP ID in 
the received ACTCDRM was less than or equal to the SSCP ID in the ACTCDRM previously 
sent. 


NAU Not Authorized: The requesting NAU does not have access to the requested 
resource. 


End User Not Authorized: The requesting end user does not have access to the 
requested resource. 


Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 

6051 Access Security Information Invalid: The request specifies an Access Security 
Information field that is unacceptable to the receiver; for security reasons, no 
further detail on the error is provided. This sense data 1s sent in FMH-7 or 
UNBIND. 

Missing Requester ID: The required requester ID was missing. 

Break: Asks the receiver of this sense code to terminate the present chain with CANCEL 

or with an FMD request carrying EC. The half-session sending the Break sense code 

enters chain-purge state when Break is sent; the half-session receiving the Break 


sense code discards the terminated chain without ever retransmitting it. 


Insufficient Resource: Receiver cannot act on the request because of a temporary lack 
of resources. 


Bytes 2 and 3 may contain the following sense code specific information: 
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0000 No specific code applies. 


0004 The RNAA request indicates that the requested address must be pre-ENA compat- 
ible, but no pre-ENA compatible address is available. 


Bracket Bid Reject--No RTR Forthcoming: BID (or BB) was received while the first 
speaker was in the in-bracket state, or while the first speaker was in the 
between-brackets state and the first speaker denied permission. RTR will not be sent. 
Bytes 2 and 3 may contain the following sense code specific information: 


0000 No specific code applies. 


0001 Bracket Bid Reject: The component was in the in-bracket state when a bracket 
request was received. 


0002 Bracket Bid Reject: The component was in the between-bracket state when a 
bracket request was received. 


Bracket Bid Reject--RTR Forthcoming: BID (or BB) was received while the first speaker 
was in the in-bracket state, or while the first speaker was in the between-brackets 
state and the first speaker denied permission. RTR will be sent. 


Function Active: <A request to activate a network element or procedure was received, 
but the element or procedure was already active. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 No specific code applies. 


0001 A session activation request was received by a boundary function to activate a 
session that was already active. 


Function Inactive: A request to deactivate a network element or procedure was 
received, but the element or procedure was not active. 


Link or Link Resource Inactive: A request requires the use of a Link or link resource 
that is not active. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 

0001 Link inactive. 

0002 Link station inactive. 

0003 Switched link connection inactive. 


Link Procedure in Process: CONTACT, DISCONTACT, IPL, or other link procedure in 
progress when a conflicting request was received. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies 

0004 Reserved. 

0005 Link problem determination test for a modem in progress. 

0006 Online terminal test in progress. 

0007 SDLC link test, level 2) in progress. 

RTR Not Required: Receiver of READY TO RECEIVE has nothing to send. 
Request Sequence Error: Invalid sequence of eres 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 
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0004 An NC_ER_TEST was to be sent as a result of receiving a ROUTE_TEST request. The 
ROUTE_TEST was sent in one subnetwork, the NC_ER_TEST was to be sent in another. 
The SSCP sending the ROUTE_TEST did not have a required alias address within the 
subnetwork where the NC_ER_TEST was to be sent. (Before sending ROUTE_TEST, the 
SSCP sends RNAA, or the installation predefines the alias address, so that an 
origin SSCP address is available within the subnetwork of the route being 
tested. This address is then specified in the NC_ER_TEST RU.) 


Receiver in Transmit Mode: A race condition: normal-flow request received while the 
half-duplex contention state was not-receive, (*S,-R), or while resources (such as 
buffers) necessary for handling normal-flow data were unavailable. (Contrast this 
sense code with X'200¢', which signals a protocol violation. } 


Request Not Executable: The requested function cannot be executed, because of a per- 
manent error condition tn the receiver. 


Invalid Station/SSCP ID: The station ID or SSCP ID in the request was found to be 
invalid. 


Session Reference Error: The request contained reference to a half-session that was 
neither active nor in the process of being activated (generally applies to network 
services requests). 


Reserved 


Control Vector Error: Invalid data for the control vector specified by the target net- 
work address and key. 


Invalid Session Parameters: Session parameters were not valid or not supported by the 
half-session whose activation was requested. 


Link Procedure Failure: A link-level procedure has failed due to link equipment fail- 
ure, loss of contact with a link station, or an invalid response to a link command. 
(This is not a path error, since the request being rejected was delivered to its des- 
tination. ) 


Unknown Control Vector: The control vector specified by a network address and key Is 
not Known to the receiver. 


Logical Unit of Work Aborted: The current unit of work has been aborted; when sync 
point protocols are in use, both syne point managers are to revert to the previously 
committed sync point. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 For LU 6.2, Backout Initiated: A transaction program or its LU has initiated 
backout. The protected resources for the distributed logical unit of work are 
to be restored to the previously committed sync point. This sense data is sent 
only in FMH-7. 


For non-LU 6.2, no specific code applies. 


Component Not Available: The LU component (a device indicated by an FM header) is not 
available. 


FM function not supported: <A function requested in an FMD RU is not supported by the 
receiver. 


Intermittent Error--Retry Requested: An error at the receiver caused an RU to be lost. 
The error is not permanent, and retry of the RU (or chain) is requested. 


Reply Not Allowed: A request requires a normal-flow reply, but the outbound data flow 
for this half-session is quiesced or shut down, and there is no delayed reply capabil- 
ity. 

Change Direction Required: A request requires a normal-flow reply, but the half-duplex 
flip-flop state is not-send, (-S,*R), CD was not set on the request, and there is no 
delayed reply capability. 


Presentation Space Alteration: Presentation space altered by the end user while the 
half-duplex state was not-send, (7-S;,*R)3; request executed. 


Presentation Space Integrity Lost: Presentation space integrity lost (e.g., cleared or 
changed) because of a transient condition--for example, because of a transient hard- 
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ware error or an end user action such as allowing presentation services to be used by 
the SSCP. (Note: The end-user action described under X'082A' and X'084A' is excluded 
here. ) | 


Resource-Sharing Limit Reached: The request received from an SSCP was to activate a 
half-session, a link, or a procedure, when that resource was at its share limit. 


LU Busy: The LU resources needed to process the request are being used; for example, 
the LU resourcés needed to process the request received from the SSCP are being used 
for the LU-LU session. 


Intervention Required at LU Subsidiary Device: A condition requiring intervention, 
such as out of paper, or power-off, or cover interlock open, exists at a subsidiary 
device. 


Request Not Executable because of LU Subsidiary Device: The requested function cannot 
be executed, due to a permanent error condition in one or more of the receiver’ s sub- 
sidiary devices. 


LU Component Disconnected: An LU component is not available because of power off or 
some other disconnecting condition. 


Invalid Count Field: A count field contained in the request indicates a value too 
long or too short to be interpreted by the receiver, or the count field is inconsist- 
ent with the length of the remaining Fields. Bytes 2 and 3 are used for sense code 
specific information: 


nnnn Bytes 2 and 3 contain a binary count that indexes (zero-origin) the first byte 
of the invalid count field. 


Invalid Parameter (with Pointer and Complemented Byte): One or more parameters con- 
tained in fixed- or variable-length fields of the request are invalid or not supported 
by the NAU that received the request. Bytes 2 and 3 are used for sense code specific 
information: 


nnmm Byte 2 contains a binary value that indexes (zero-origin) the first byte that 
contained an invalid parameter. Byte 3 contains a transform of the first byte 
that contained an invalid parameter: the bits that constitute the one or more 
invalid parameters are complemented, and all other bits are copied. 


RPO Not Initiated: A power-off procedure for the specified node was not initiated 
because one or more other SSCPs have contacted the node, or because a CONTACT, DUMP, 
IPL, or DISCONTACT procedure is itn progress for that node. 


Invalid Parameter (with Pointer Only): The request contained aie fixed- or 
variable-length field whose contents are invalid or not supported by the NAU that 
received the request. Bytes 2 and 3 are used for sense code specific information: 


nnnn Bytes 2 and 3 contain a two-byte binary count that indexes (zero-origin) the 
first byte of the fixed- or variable-length field having invalid contents. 


Note: This sense code is not used to report an invalid value in an MS major vector. 
If the invalid value occurs in a formatted MS subvector, then 086B is used. If it 
occurs in an unformatted subvector, then 0870 is used. 


PLU/SLU Specification Mismatch: For a specified LU-LU session, both the origin LU 
(OLU) and the destination LU (DLU) have only the primary capability or have only the 
secondary capability. 


‘Queuing Limit Exceeded: For an LU-LU session initiation request CINIT, CDINIT, or 


INIT-OTHER-CD) specifying (1) Initiate or Queue (if Initiate not possible) or (2) 
Queue Only, the queuing limit of either the OLU or the DLU, or both, was exceeded. 


Reserved 


LU-LU or SSCP-LU Session Being Taken Down: At the time an LU-LU session initiation or 
termination request is received, the SSCP of at least one of the LUs is either proc- 
essing a CDTAKED request or is in the process of deactivating the associated SSCP-LU 
session. 


LU Not Enabled: At the time an LU-LU session initiation request is received at the 
SSCP, at least one of the two LUs, although having an active session with its SSCP, is 
not ready to accept CINIT or BIND requests. 
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Invalid PCID: the received PCID for a new session duplicated the PCID assigned to 
another session, or the received PCID intended as an identifier for an existing ses- 
sion could not be associated with such an existing session. 


Bytes 2 and 3 following the sense code contain sense code specific information, Set- 
tings allowed are: 


0000 No specific code applies. 


0001 The PCID contained itn CDINIT(Initiate or Queue), INIT-OTHER-CD, or CDTAKED 
duplicates a PCID received previously in one of these requests. 


Domain Takedown Contention: While waiting for a response to a CDTAKED, a CDTAKED 
request is received by the SSCP containing the SSCP-SSCP primary, half-session. Con- 
tention is resolved by giving preference to the CDTAKED sent by the primary 
half-session. 


Dequeue Retry Unsuccessful--Removed from Queue: The SSCP cannot successfully honor a 
CDINIT(Dequeve) request (which specifies “leave on queue if dequeue-retry is unsuc- 
cessful") to dequeue and process a previously queued CDINIT request (e.g.» because the 
LU in its domain is still not available for the specified session), and removes the 
queued CDINIT request from its queue. 


Reserved 


Terminate Contention: While waiting for a response to a CDTERM, a CDTERM is received 
by the SSCP of the SLU. Contention is resolved by giving preference to the CDTERM 
sent by the SSCP of the SLU. 


Procedure Invalid for Resource: The named procedure is not supported in the receiver 
for this type of resource (e.g.5 (1) SETCV specifies boundary function support for a 
type 1 node but the capability 1s not supported by the receiving node, or (2) the PU 
receiving an EXECTEST or TESTMODE is not the primary PU for the target link.) 


Duplicate Network Address: In a cross-domain LU-LU session initiation request, the 
SSCP of the DLU determines that the OLU network address specified in the CDINIT 
request is a duplicate of an LU network address assigned to a different LU name. 


SSCP-SSCP Session Not Active: The SSCP-SSCP session, which is required for the proc- 
essing of a network services request, 1s not active; e.g., at the time an LU-LU ses- 
Sion initiation or termination request is received, at least one of the following 
conditions exists: | 


e The SSCP of the ILU and the SSCP of the OLU do not have an active session with 
each other, and therefore INIT-OTHER-CD cannot flow. 


e The SSCP of the OLU and the SSCP of the DLU do not have an active session with 
each other, and therefore CDINIT or CDTERM cannot flow. 


Required Synchronization Not Supplied: For example, a secondary LU (LU type 2 or 3) 
received a request with Write Control Code = Start Print, along with RQE and -CD. 


Initiation Dequeue Contention: While waiting for a response to a CDINIT(Dequeue), a 
CDINIT(Dequeue) is received by the SSCP of the SLU. Contention is resolved by giving 
preference to the CDINIT(Dequeue) sent by the SSCP of the SLU. 


Permission Rejected--SSCP Will Be Notified: The receiver has denied an implicit or 
explicit request of the sender; when sent in response to BIND, it implies that the 
secondary LU will notify the SSCP (via NOTIFY vector key X'OC') when a BIND can be 
accepted, and the SSCP of the SLU supports the notification. (See the X'080A' sense 
code for a contrasting response. ) 


ERP Message Forthcoming: The received request was rejected for a reason to be speci- 
fied in a forthcoming request. 


Restart Mismatch: Sent in response to STSN, SDT, or BIND to indicate that the second- 
ary half-session is trying to execute a:‘resynchronizing restart but has received 
insufficient or incorrect information. 


Cryptography Function Inoperative: The receiver of a request was not able to decipher 
the request because of a malfunction in its cryptography facility. 


Reserved 


Appendix G. Sense Data G-7 


084A 


084B 


084C 


084D 


084E 


084F 


0850 


0851 


0852 


0853 


0854 


0855 


0856 


Presentation Space Alteration: The presentation space was altered by the end user 
while the half-duplex state was not-send, (-S,*R)3; request not executed. 


Requested Resources Not Available: Resources named in the request, and required to 
honor it, are not currently available. It is not Known when the resources will be 
made available. 


Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 

6002 The resource identified by the destination program name (DPN) is not supported. 
6003 The resource identified by the primary resource name (PRN) is not supported. 


6031 Transaction Program Not Available--Retry Allowed: The FMH-5 Attach command 
specifies a transaction program that the receiver is unable to start. Either 
the program is not authorized to run or the resources to run it are not avail- 
able at this time. The condition is temporary. The sender is responsible for 
subsequent retry. This sense data is sent only in FMH-7. 


Permanent Insufficient Resource: Receiver cannot act on the request because resources 
required to honor the request are permanently unavailable. The sender should not 
retry immediately because the situation is not transient. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 For LU 6.2) Transaction Program Not Available--No Retry: The FMH-5 Attach com- 
mand specifies a transaction program that the receiver is unable to start. The 
condition is not temporary. The sender should not retry immediately. This 
sense data is sent only in FMH-7. 


For non-LU 6.2, no additional information is specified. 


hnnn where h28, i.e., the high-order bit in byte 2 is set to 1. The 15 low-order 
bits of bytes 2 and 3 contain a binary count that indexes (zero-origin) the 
first byte of the field found to be in error. 


Invalid Session Parameters--BF: Session parameters were not valid or were unaccepta- 
ble to the boundary function. Bytes 2 and 3 following the sense code contain a binary 
count that indexes (zero origin) the first byte of the fixed- or variable-length field 
having invalid contents. 


Invalid Session Parameters--PRI: A positive response to an activation request (e.g., 
BIND) was received and was changed to a negative response because of invalid session 
parameters carried in the response. The services manager receiving the response will 
send a deactivation request for the corresponding session. 


Reserved 


Link-Level Operation Cannot Be Performed: An IPL, dump, or RPO cannot be performed 
through the addressed link station because the system definition or current state of 
the hardware configuration does not allow it. 


Session Busy: Another session that is needed to complete the function being requested 
on this session is temporarily unavailable. 


Duplicative Session Activation Request: Two session activation requests have been 
received with related identifiers. The relationship of the identifiers and the 
resultant action varies by request. For BIND, it means that the BIND request was 
received with the same session instance identifier (in the structured subfield X'03' 
of the User Data field) as an active session's; the current request is refused. 


TERMINATE(Cleanup) Required: The SSCP cannot process the termination request, as it 
requires cross-domain SSCP-SSCP services that are not available. (The corresponding 
SSCP-SSCP session is not active.) TERMINATE(Cleanup) is required. 

Retired, formerly used for product-specific information. 


Reserved 


SSCP-SSCP Session Lost: Carried in the Sense Data field in a NOTIFY (Third-Party 
Notification vector, X'03') or -RSPCINIT_OTHER) sent to an ILU to indicate that the 
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activation of the LU-LU session is uncertain because the SSCP(ILU)-SSCP(OLU) session 
has been lost. (Another sense code, X'0842', is used when it is Known that the LU-LU 
session activation cannot be completed. ) 


SSCP-LU Session Not Active: The SSCP-LU session, required for the processing of a 
request, is not active; e.g.s in processing REQECHO, the SSCP did not have an active 
session with the target LU named in the REQECHO RU. 


Reserved 


REQECHO Data Length Error: The specified length of data to be echoed (in REQECHO) vio- 
lates the maximum RU size limit for the target LU. 


Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 


Function Not Supported--Continue Session: The function requested is not supported; 
the function may have been specified by a request code or some other field, control 
character, or graphic character in an RU. Bytes 2 and 3 are used for sense code spe- 
cific information: 


nnnn Bytes 2 and 3 contain a two-byte binary count that indexes (zero-origin) the 
first byte in which an error was detected. This sense code is used to request 
that the session continue, thereby ignoring the error. 


Invalid COS Name: The class of service (COS) name, either specified by the ILU or 
generated by the SSCP of the SLU from the mode table is not in the "COS name to VR 
identifier list" table used by the SSCP of the PLU. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 COS name was generated by the SSCP. 
0001 COS name was generated by the ILU. 


0003 CDINIT request (or response) contains a Session Initiation control vector that 
has class of service (COS) name fields that have not been properly specified. 
If the RU is a positive response, it is changed into a negative response and 
sent to the request sender; a CDTFERM is sent to the CDINIT response sender. 
(This is to cover a system definition error in the event a gateway SSCP douwn- 
stream from another gateway SSCP receives a CDINIT or FPSP(CDINIT) without valid 
information in the appropriate COS name fields of the Session Initiation control 
vector. ) 


Medium Presentation Space Recovery: An error has occurred on the current presentation 
Space. Recovery consists of restarting at the top of the current presentation space. 
The sequence number returned is of the RU in effect at the top of the current presen- 
tation space. 


nnnn Bytes 2 and 3 following the sense code contain the byte offset from the begin- 
ning of the RU to the first byte of the RU that is displayed at the top of the 
current presentation space. 


Referenced Local Character Set Identifier (LCID) Not Found: A referenced character 
set does not exist. Bytes 2 and 3 may contain the following sense code specific 
information: 

0000 No specific code appplies. 

hnnn where h28, 1.e., the high-order bit in byte 2 is set to 1. The 15 low-order 


bits of bytes 2 and 3 contain a binary count that indexes (zero-origin) the 
first byte of the field found to be in error. 
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Function Abort: The conversation was terminated abnormally. Other terminations may 
occur after repeated reexecutions; the request sender is responsible to detect such a 
loop. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 For LU 6.2, Premature Conversation Termination: The conversation is terminated 
abnormally; for example, the transaction program may have issued a DEALLO- 
CATE_ABEND verb, or the program may have terminated (normally or abnormally) 
without explicitly terminating the conversation. This sense data is sent only 
in FMH-7. 


For non-LU 6.2, no additional information is specified. 


0001 System Logic Error--No Retry: A system logic error has been detected. No retry 
of the conversation should be attempted. This sense data is sent only in FMH-7. 


0002 Excessive Elapsed Time--No Retry: Excessive time has elapsed while waiting for 
a required action or event. For example, a transaction program has failed to 
issue_a conversation-related protocol boundary verb. No retry of the conversa- 
tion should be attempted. This sense data is sent only in FMH-7. 


Retired. 
Retired. 


Sync Event Response: Indicates a required negative response to an (RQE,CD) synchroniz- 
ing request. 


No Panels Loaded: Referenced format not found because no panels are loaded for the 
display. 


Panel Not Loaded: The referenced panel is not loaded for the display. 


Subfield Key Invalid: A subfield key in an MS subvector was not valid in the condi- 
tions under which it was processed. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


nnmm Byte 2 following the sense code contains the subvector key (nn) of the subvector 
containing the unrecognized subfield, and byte 3 contains the unidentified sub- 
field key (mm). 


Subfield Value Invalid: The value of a subfield in an MS subvector is invalid for the 
receiver. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


nnmm Byte 2 following the sense code contains the subvector key (nn) of the subvector 
containing the invalid subfield, and byte 3 contains the subfield key (mm) of 
the invalid subfield. 


(See sense code 0870 for the case in which the invalid value occurs in an unformatted 
subvector (that 15, one not containing subfields with Keys and lengths), or in the 
unformatted portion of a partially formatted subvector. ) 


Required Subvector Missing: One or more MS subvectors that are required by the 
receiver to perform some function are missing from the received list of subvectors. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


nnoo Byte 2 following the sense code contains the subvector key (nn) of one of the 
subvectors that 1s missing. Byte 3 is reserved (00). 


Note: See the X'080C0006' sense data for the case in which the major vector key is 


recognized but a subvector representing the function to be performed cannot be identi- 
fied. | 


0401 The SNA Address List (X'04') subvector is required, but was not the first sub- 
vector in the major vector. 
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Required Subfield Missing: An NMVT subvector lacks one or more subfield keys that are 
required by the receiver to perform the function requested. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


nnmm Byte 2 following the sense code contains the subvector key (nn) of the subvector 
lacking a required subfield, and byte 3 contains the subfield key (mm) of a 
missing subfield. 


Length Error: A length field within an MS major vector is invalid, or two or more 
length fields are incompatible. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 Reserved 
0001 The MS major vector length is incompatible with the RU length. 


0002 The sum of the MS subvector lengths is incompatible with the MS major vector 
length. 


nn03 The sum of the subfield lengths in a MS subvector is incompatible with the sub- 
vector length. Byte 3 following the sense code contains the subvector key (nn). 


nmn05 MS subvector length invalid. Byte 2 following the sense code contains the rele- 
vant subvector Key (nn). (This is specified only if the sum of the subvector 
lengths is compatible with the major vector length. ) 


nn06 Subfield length invalid. Byte 2 following the sense code contains the subvector 
key (nn) of the MS subvector containing the invalid subfield length. (This is 
specified only if the sum of the subfield lengths is compatible with the subvec- 
tor length. } 


Unformatted Subvector Value Invalid: A value in an unformatted MS subvector, or in an 
unformatted portion of a partially formatted MS subvector, is invalid. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


nnxx Byte 2 following the sense code contains the subvector key (nn) of the MS sub- 
vector containing the invalid value. Byte 3 contains a one-byte binary count 
that indexes the first byte in which the invalid value falls. The indexing is 
zero-origin, from the beginning of the subvector. 


(See sense code 086B for the case in which the invalid value occurs in a formatted MS 
subvector, that 1s, one containing subfields with keys and lengths, or in the format- 
ted portion of a partially formatted subvector. ) 


Read Partition State Error: A Read Partition structured field was received while the 
display was in the retry state. 


Orderly Deactivation Refused: An NC_DACTVR(Orderly) request has been received, but 
Sessions are assigned to the VR and it will not be deactivated. 


Virtual Route Not Defined: No ERN is designated to support this VRN. 


ER Not in a Valid State: The ER supporting the requested VR is not in a state allow- 
ing VR activation. 


Incorrect or Undefined Explicit Route Requested: The reverse ERNs specified in the 
NC_ACTVR do not contain the ERN defined to be used for the VR requested, or the ERN 
designated to be used for the VR is not defined. 


Nonreversible Explicit Route Requested: The ERN used by the NC_ACTVR does not use the 
same sequence of transmission groups (in reverse order) as the ERN that should be used 
for the RSP(NC_ACTVR). 


Resource Mismatch: The receiver of a request has detected a mismatch between its defi- 
nition of an affected resource and the actual configuration. 
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Bytes 2 and 3 may contain the following sense code specific information: 


0000 No specific code applies. 


0001 Link Defined as Switched Is Nonswitched: A link defined to an ACTLINK receiver 
as being switched was found to be nonswitched during the activation attempt. 


0002 Link Defined as SDLC Is Non-SDLC: A link defined to an ACTLINK receiver as 
being SDLC was found to be non-SDLC during the activation attempt. 


0003 Link Defined as Having Automatic Connect-Out Capability Does Not: <A link 
defined to an ACTLINK receiver as having automatic connect-out capability was 
found to lack it during the activation attempt. 


0004 ACTLINK Received for a Resource Other Than a Link: An ACTLINK was received that 
resolved to a local device address representing a device other than a link. 


Insufficient Storage: The storage resource required for a data format is not avail- 
able. 


Storage Medium Error: A permanent error has occurred involving a storage medium. 
Format Processing Error: A processing error occurred during data formatting. 


Resource Unknown: The request contains a session key that does not identify a session 
Known to some gateway node; e.g.» a session activation request arrives at a gateway 
node after it has released the address transform for the intended session. 


SSCP-PU Session Not Active: A gateway SSCP-PU session that is needed to establish an 
address transform for the intended cross-network LU-LU session was not active. 


Session Services Path Error: A session services request--CDINIT, INIT_OTHER_CD, NOTI- 
FY, or DSRLST--cannot be rerouted along a path of SSCP-SSCP sessions. This capability 
is required, for example, to set up a cross-network LU-LU session. 


Bytes 2 and 3 contain sense code specific information that indicates the specific rea- 
son for not rerouting the request. Settings allowed are: 


0000 Reserved 


0001 An SSCP has attempted unsuccessfully to reroute a session services request to 
its destination via one or more adjacent SSCPs; this value is sent by a gateway 
SSCP when it has exhausted trial-and-error rerouting. 


0002 An SSCP is unable to reroute a session services request because a necessary 
routing table is not available, that is, there is no adjacent SSCP table corre- 
sponding to the rerouting key in the Resource Identifier control vector. The 
receiver of this value will, if possible, try rerouting to another SSCP. 


0003 An LU definition is needed to process the session services request. The LU has 
not been predefined and the request receiver does not support dynamic definition. 
of LUs residing in other subnetworks or domains. 


0004 Reserved 


0005 An SSCP 1s unable to use the gateway node specified in CDINIT because that gate- 
Way node cannot allocate an address transform for the intended cross-network 
LU-LU session. 


0006 An SSCP is able to use only a subset of the alternate gateway nodes available to 
it. However, for the subset that it can use, none can provide the needed alias 
address pair. 


0007 Reserved 


0008 A gateway SSCP is unable to reroute a CDINIT request because the adjacent SSCP 
does not support notification of resource availability (see control vector X'06' 
byte 5, bit 0) as requested in the received CDINIT. Resource availability 
notification support must have been indicated by the SSCP on the DLU side of a 
gateway SSCP if CDINIT rerouting is required. 


SSCP Visit Count Exceeds Limit: The SSCP visit count specified in the session serv- 
ices request--CDINIT, INIT_OTHER_CD, or DSRLST--has been decremented to 0. The ses- 
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0881 


0884 


0886 


0887 


0888 


0889 


088A 


Sion services request has been routed through an excessive number of SSCPs. (The 
SSCPs ate not necessarily distinct. ) 


ACTCDRM Failure--REQACTCDRM Sent: An SSCP-SSCP session-activation request, ACTCDRM, 
cannot be rerouted to a gateway SSCP because, at some gateway PU, the necessary trans- 
form is not complete and the gateway PU has sent REQACTCDRM to the gateway SSCP. 


ACTCDRM Failure--No REQACTCDRM Sent: An SSCP-SSCP session activation request, 
ACTCDRM, cannot be rerouted to the destination SSCP because, at some gateway node PU, 
the necessary transform is not complete and REQACTCDRM cannot be sent to the destina- 
tion SSCP because the gateway SSCP-PU session 1s not active or the intended SSCP ses- 
sion partner does not provide gateway services. 


Subnetwork Rerouting Not Supported: An SSCP received a_esession. services 
request--CDINIT, INIT_OTHER_CD, NOTIFY(Vector Key=X'01'), or DSRLST--from an SSCP in 
its subnetwork that, if rerouted, would not cross a subnetwork boundary. The SSCP 
does not support rerouting within a subnetwork. 


Dequeue Retry Unsuccessful--Session Remains Queued: The SSCP cannot successfully hon- 
or a CDINIT(Dequeue) request. The request specifies "leave on queue if dequeue-retry 
is unsuccessful."" The SSCP has left the queued session on its queue. 


Name Conflict: A name specified in an RU is unknown for the specified resource type. 
When a name conflict is detected, further name checking ceases; multiple name con- 
flicts are not reported or detected. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 Reserved. 

0001 DLU real network name is unknown. 

0002 DLU alias network name is unknown. 

0003 OLU real network name is unknown. 

0004 OLU alias network name ts unknown. 

Transaction Program Error: The transaction program has detected an error. 
This sense code is sent only tn FMH-7. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 Program Error--No Data Truncation: The transaction program sending data 
detected an error but did not truncate a logical record. 


Program Error--Purging: The transaction program receiving data detected an 
error. All remaining information, if any, that the receiving program had not 
yet received, and that the sending program had sent prior to being notified of 
the error, is discarded. 


0001 Program Error--Data Truncation: The transaction program sending data detected 
an error and truncated the logical record it was sending. 


0100 Service Transaction Program Error--No Data Truncation: The service transaction 
program sending data detected an error and did not truncate a logical record. 


Service Transaction Program Error--Purging: The service transaction program 
receiving data detected an error. All remaining information, if any, that the 
receiving service transaction program had not yet received, and that the sending 
service transaction program had sent prior to being notified of the error, is 
discarded. 


0101 Service Transaction Program Error--Data Truncation: The service transaction 
program sending data detected an error and truncated the logical record it was 
sending. 


Resource Unavailable--NOTIFY Forthcoming: The SSCP cannot satisfy the request because 


a required resource is temporarily unavailable. When the required resource becomes 
available, NOTIFY NS(s) key X'07' or X'08' will be sent. 
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088B 


088D 


O88E 


Bytes 2 and 3 may contain the following sense code specific information that indicates 
the specific reason for not rerouting the request: 


0000 Reserved 


0001 SSCP-SSCP Session Not Active: A SSCP-SSCP session required to reroute the 
cross-network request was not active. 


0002 Reserved 


0003 SSCP-LU session not active: The SSCP(DLU) is currently not in session with the 
DLU. 


0004 LU session limit exceeded: The DLU jis currently at its session Limit and the 
requested session would cause the limit to be exceeded. 


BB Not Accepted-~-BIS Reply Requested: Sent in response to a BB (either an LUSTAT bid 
or an Attach) to indicate that the receiver has sent a BIS request and wishes to ter- 
minate the session without processing any more conversations, but without sending an 
UNBIND. A BIS reply is requested so that the negative response sender may send a 
normal | UNBIND. This sense code is sent only by LUs~= not supporting 
change-number-of-session protocols. 


Duplicate Network Name: An SSCP has detected a violation of the requirement that net- 
work names used across multiple domains be unique within the multiple-domain network. 
For example, the SSCP(DLU) has detected that the OLU name received in CDINIT is cur- 
rently also defined in the domain >f the SSCP(DLU). 


ENA Address Mismatch: An SSCP detected that an ENA LU has an address too large for 
one of the pre-ENA components (LU or SSCP) involved in the session to support. If 
both LUs are in the same domain, the SSCP responds negatively to the INIT-SELF or 
INIT-OTHER with this sense code. If the LUs are in different domains, either: 


® The SSCP(OLU) detected the mismatch, and responds negatively to the INIT-SELF or 
INIT-OTHER with this sense code; or 


© The SSCP(OLU) could not detect the mismatch and sent CDINIT to the SSCP(DLU), 
which detected the mismatch and responds negatively to the CDINIT with this sense 
code; upon receiving the -RSP(CDINIT), the SSCP(OLU) responds negatively to the 
INIT-SELF or INIT-OTHER with this sense code. 


PAA EO ARS =| SEN 


This category indicates that the RU was delivered to the intended NAU component, but could not 
be interpreted or processed. This condition represents a mismatch of NAU capabilities. 


Category and modifier (Cin hexadecimal): 


1001 


1002 


1003 


RU Data Error: Data tn the request RU jis not acceptable to the receiving component; 
for example, a character code is not in the set supported, a formatted data field is 
not acceptable to presentation services, a value specified in the length field (LL) of 
a structured field is invalid, or a required name in the request has been omitted. 


RU Length Error: The request RU was too long or too short. 


Function Not Supported: The function requested is not supported. The function may 
have been specified by a formatted request code, a field in an RU, or a control char- 
acter. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0000 No specific code applies. 


0001 The half-session receiving the request did not perform the function because it 
is not capable of doing so. The requesting half-session requested a function 
that the receiver does not support and the receiver did not specify that it was 
capable of supporting the function at session activation; consequently, there is 
an apparent mismatch of half-session capabilities. 
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1004 


1005 


1006 


1007 


1008 


Note: This is to cover a system error. For example, if the PU receiving a 
SETCV( Vector Key=X'15') is not a gateway PU, that is, the PU did not indicate in 
the ACTPU response that it is a gateway PU, the PU reports to the SSCP that sent 
the SETCV that there is an apparent mismatch of half-session capabilities. 


0002 The half-session receiving the request did not perform the function, though it 
is capable of doing so. The requesting half-session did not specify at session 
activation that it was capable of supporting the function; consequently, there 
15 an apparent mismatch of half-session capabilities. 


Note: This 1s to cover a system error. For example, if the SSCP sending a 
SETCV( Vector Key=X'15') is not Known to the receiving PU as a gateway SSCP, that 
is, the SSCP did not indicate in ACTPU that it is a gateway SSCP, the PU reports 
a mismatch of capabilities. 


0003 The component received an unsupported normal-flow DFC command. 
0004 The component received an unsupported expedited-flow DFC command. 
0005 The component received a network control command during an LU-SSCP session. 


0006 The component received an unsupported session control command during an LU-SSCP 
session. 


0007 The component received an unsupported data flow control command with LU-SSCP 
session specified. 


6002 The resource identified by the destination program name (DPN) 1s not supported. 
6003 The resource identified by the primary resource name (PRN) 1s not supported, 
(Note: This sense code can also be used instead of sense code X'0826'.) 

Reserved. 


Parameter Error: A parameter modifying a control function is invalid, or outside the 
range allowed by the receiver. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 


0001 For NMVT, the address type field in an SNA Address List subvector does not match 
the address type required by the command subvector. 


Reserved 

Category Not Supported: DFC, SC, NC, or FMD request was received by a half-session not 
supporting any requests tn that category; or an NS request byte 0 was not set to a 
defined ‘value, or byte 1 was not set to an NS category supported by the receiver. 
Invalid FM Header: The FM header was not understood or translatable by the receiver, 
or an FM header was expected but not present. This sense code is sent in FMH-7 or 
UNBIND. 


Bytes 2 and 3 may contain the following sense code specific information: 


0000 Reserved. 


‘200E Invalid Concatenation Indicator: The concatenation indicator is on but concat- 


enation is not alloned. 


201D FM Header and Associated Data Mismatch: The FM header indicated associated data 
would or would not follow (e.g., FM header 7 followed by log data, or FM header 
5 followed by program initialization parameters), but this indication was in 
error; or a previously received RU [e.g., -RSP(0846)] implied that an FM header 
would follow, but none was received. 


4001 Invalid FM Header Type: The type of the FM header is other than 5 or 7. 


6000 FM Header Length Not Correct: The value in the FM header Length field differs 
from the sum of the lengths of the subfields of the FM header. 
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6005 Access Security Information Length Field Not Correct: The value in the Access 
Security Information Length field differs from the sum of the lengths of the 
Access Security Information subfields. 


6009 Invalid Parameter Length. The field that specifies the length of fixed-length 
parameters has an invalid setting. 


600B Unrecogized FM Header Command Code: The partner LU received an FM header com- 
mand code that it does not recognize. For LU 6.2, this sense data is sent only 
in FMH-7. 


6011 Invalid Logical Unit of Work: The, LUW Length field (in a Compare States GDS 
variable or an FMH-5) is incorrect or the LUW is invalid or a LUWID is not pres- 
ent but is required by the setting of the synchronization level field. 


6021 Transaction Program Name Not Recognized: The FMH-5 Attach command specifies a 
transaction program name that the receiver does not recognize. This sense data 
is sent only in FMH-7. 


6031 PIP Not Allowed: The FMH-5 Attach command specifies program initialization 
parameter (PIP) data is. present but the receiver does not support PIP data for 
the specified transaction program. This sense data is sent only in FMH-7. 


6032 PIP Not Specified Correctly: The FMH-5 Attach command specifies a transaction 
program name that requires program initialization parameter (PIP) data and 
either the FMH-5 specifies PIP data is not present or the number of PIP sub- 
fields present does not agree with the number required for the program. This 
sense data is sent only in FMH-7. 


6034 Conversation Type Mismatch: The FMH-5 Attach command specifies a conversation 
type that the receiver does not support for the specified transaction program. 
This sense data is sent only in FMH-7. 


6040 Invalid Attach Parameter: A parameter in the FMH-5 Attach command conflicts 
with the statement of LU capability previously provided in the BIND negotiation. 


6041 Synchronization Level Not Supported: The FMH-5 Attach command specifies a syn- 
chronization level that the receiver does not support for the specified trans- 
action program. This sense data is sent only in FMH-7. 


1009 Format Group Not Selected: No format group was selected before issuing a Present Abso- 
lute or Present Relative Format structured field to a display. 


PED OE EY RY UO 


6-16 


This category indicates a sequence number error, or an RH or RU that is not allowed for the 
receiver's current session control or data flow control state. These errors prevent delivery of 
the request to the intended component. | 

Category and modifier (in hexadecimal): 


2001 Sequence Number: Sequence number received on normal-flow request was not 1 greater 
than the last. 


2002 Chaining: Error in the sequence of the chain indicator settings (BCI, ECI), such as 
first, middle, first. 


Bytes 2 and 3 may contain the following sense code specific information: 

0000 No specific code applies. 

0001 The receiver received a middle or end-chain request when in the in-chain state. 
0002 The receiver received a begin-chain request when in the in-chain state. 


2003 Bracket: Error resulting from failure of sender to enforce bracket rules for session. 
(This error does not apply to contention or race conditions. ) 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: 
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2004 


2005 


2006 


2007 


2008 


2009 


200A 


200B 


200C 


200D 


200E 


200F 


2010 


2011 


2012 


0000 No specific code applies. 


0001 The receiver received a begin-bracket request before receiving a response to its 
own previously sent begin-bracket request. 


0002 The receiver received a begin-bracket request not specifying begin-bracket when 
in the between-bracket state. 


0003 The receiver received an out-of-sequence LUSTAT command. 


Direction: Error resulting from a normal-flow request received while the half-duplex - 
flip-flop state was not Receive. 


Data Traffic Reset: An FMD or normal-flow DFC request received by a half-session whose 
session activation state was active, but whose data traffic state was not active. 


Data Traffic Quiesced: An FMD or DFC request received from a half-session that has 
sent QUIESCE COMPLETE or SHUTDOWN COMPLETE and has not responded to RELEASE QUIESCE. 


Data Traffic Not Reset: A session control request (e.g., STSN), allowed only while the 
data traffic state 1s reset, was received while the data traffic state was not reset. 


No Begin Bracket: An FMD request specifying BBI=BB was received after the receiver 
had previously received a BRACKET INITIATION STOPPED request. 


Session Control Protocol Violation: An SC protocol has been violated; a request, 
allowed only after a successful exchange of an SC request and its associated positive 
response, has been received before such successful exchange has occurred (e.g.,» an FMD 
request has preceded a required CRYPTOGRAPHY VERIFICATION request). The request code 
of the particular SC request or response required, or X'00' if undetermined, appears 
in the fourth byte of the sense data. 


Immediate Request Mode Error: The immediate request mode protocol has been violated 
by the request. 


Queued Response Error: The Queued Response protocol has been violated by a request, 
1.e@., QRI=-QR when an outstanding request had QRI=QR. 


ERP Sync Event Error: The ERP syne event protocol in DFC has been violated, e.g., 
after receiving a negative response to a chain, a request other than a request solic- 
iting a synchronization event response was sent to DFC_SEND and rejected. 


Response Owed Before Sending Request: An attempt has been made in half-duplex 
(flip-flop or contention) send/receive mode to send a normal-flow request when a 
response to a previously received request has not yet been sent. 


Response Correlation Error: A response was received that cannot be correlated to a 
previously sent request. 


Response Protocol Error: <A violation has occurred in the response protocol; e.g.» a 
+RSP to an RQE chain was generated. 


BIS Protocol Error: A BIS protocol error was detected; e.g., a BIS request was 
received after a previous BIS was received and processed. 


Pacing Error: A normal-flow request is received by a half-session after the pacing 


count has been reduced to 0 and before a pacing response has been sent. 


Invalid Sense Code Received: A negative response was received that contains an 
SNA-defined sense code that cannot be used for the sent request. 


RH USAGE ERROR (CATEGORY CODE = X'40') 


SS AT EER REE ESE EE 0 METERED 


This category indicates that the value of a field or combination of fields in the RH violates 
architectural rules or previously selected BIND options. These errors prevent delivery of the 
request to the intended component ana are independent of the current states of the session. 
They may result from the failure of the sender to enforce session rules. Detection by the 
receiver of each of these errors is optional. ; 
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Category and modifier (in hexadecimal): 


4001 


4002 


4003 


4004 


4005 


4006 


4007 


4008 


4009 


400A 


400B 


400C 


400D 
400E 


400F 


4010 


4011 


4012 


4013 


4014 


4015 


4016 


4017 


Invalid SC or NC RH: The RH of a session control (SC) or network control (NC) request 
was invalid. For example, an SC RH with pacing request indicator set to 1 is invalid. 


Reserved 


BB Not Allowed: The Begin Bracket indicator (BBI) was specified incorrectly, e.g., 
BBI=BB with BCI=-~BC. 


CEB or EB Not Allowed: The Conditional End Bracket indicator (CEBI) or End Bracket 
indicator (EBI) was specified incorrectly, e.g., CEBI=CEB when ECI=-EC or EBI=EB with 
BCI=-BC, or by the primary half-session when only the secondary may send EB, or by the 
secondary when only the primary may send EB. 


Incomplete RH: Transmission shorter than full TH-RH. 
Exception Response Not Allowed: Exception response was requested when not permitted. 
Definite Response Not Allowed: Definite response was requested when not permitted. 


Pacing Not Supported: The Pacing indicator was set on a request, but the receiving 
half-session or boundary function half-session does not support pacing for this ses- 
sion. | 


CD Not Allowed: The Change Direction indicator (CDI) was specified incorrectly, e.g., 
CDI=CD with ECI=-EC , or CDI=CD with EBI=EB. 


No-Response Not Allowed: No-response was specified on a request when not permitted. 
(Used only on EXR.) 


Chaining Not Supported: The chaining indicators (BCI and ECI) were specified incor- 
rectly, e.g., chaining bits indicated other than (BC,EC), but multiple-request chains 
are not supported for the session or for the category specified in the request header. 


Brackets Not Supported: The bracket indicators (BBI, CEBI, and EBI) were specified 
incorrectly, e.g.» a bracket indicator was set (BBI=BB, CEBI=CEB, or EBI=EB), but 
brackets are not used for the session. 


CD Not Supported: The Change-Direction indicator was set, but is not supported. 
Reserved 


Incorrect Use of Format Indicator: The Format indicator (FI) was specified incorrect- 
ly, e.g.» FI was set with BCI=-BC, or FI was not set on a DFC request. 


Alternate Code Not Supported: The Code Selection indicator (CSI) was set when not sup- 
ported for the session. 


Incorrect Specification of RU Category: The RU Category indicator was specified incor- 
rectly, e.g.» an expedited-flow request or response was specified with RU Category 
indicator = FMD. 


Incorrect Specification of Request Code: The request code on a response does not 
match the request code on its corresponding request. 


Incorrect Specification of (SDI, RTI): The Sense Data Included indicator (SDI) and the 
Response Type indicator (RTI) were not specified properly on a response. The proper 
value pairs are (SDI=SD, RTI=negative) and (SDI=-SD, RTI=positive). 


Incorrect Use of (DRII, DR2I, ERI): The Definite Response 1 indicator (DR1I), Definite 
Response 2 indicator (DR2I), and Exception Response indicator (ERI) were specified 
incorrectly, e.g.» a SIGNAL request was not specified with DRII=DR1, DR2I=-DR2, and 
ERI=-ER. | 


Incorrect Use of QRI: The Queued Response indicator (QRI) was specified incorrectly, 
@.g.» QRI=QR on an expedited-flow request. 


Incorrect Use of EDI: The Enciphered Data indicator (EDI) was specified incorrectly, 
e.g.» EDI=ED on a DFC request. 


Incorrect Use of PDI: The Padded Data indicator (PDI) was specified incorrectly, e.g.» 
PDI=PD on a DFC request. 
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4018 Incorrect Setting of QRI with Bidder's BB: The first speaker half-session received a 
BB chain requesting use of a session (via LUSTAT(X'0006')), but the QRI was specified 
incorrectly, 1.e., QRI = ~QR. 


4019 Incorrect Indicators with Last-In-Chain Request: <A last-in-chain request has speci- 
fied incompatible RH settings, e.g., RQE*¥, CEBI=-CEB, and CDI=-CD. 


4021 QRI Setting in Response Different From That in Request: The QRI setting in the 
response differs from the QRI setting in the corresponding request. 


PATH ERROR (CATEGORY CODE = X'80') 


OEE Came 86 GEE eerN || nee = ED 0 hmEEmEneweromerten 


This category indicates that the request could not be delivered to the intended receiver, 
because of a path outage, an invalid sequence of activation requests, or one of the listed path 
information unit (PIU) errors. Some PIU errors fall into other categories; for example, 
sequence number errors are sense code category X'20'. <A path error received while the session 
is active generally indicates that the path to the session partner has been lost. 

Category and modifier (in hexadecimal ): 


8001 Intermediate Node Failure: Machine or program check in a node providing intermediate 
routing function. A response may or may not be possible. 


8002 Link Fatlure: Data link failure. 


8003 NAU Inoperative: The NAU is unable to process requests or responses, e.g., the NAU has 
been disrupted by an abnormal termination. 


8004 Unrecognized Destination: <A node in the path has no routing information for the des- 
tination specified either by the SLU name in a BIND request or by the TH. 


Bytes 2 and 3 may contain the following sense code specific information: 
0000 No specific code applies. 


0001 A request was received by a gateway function that could not be rerouted because 
of invalid or incomplete routing information. 


8005 No Session: No half-session is active in the receiving end node for the indicated 
origination-destination pair, or no boundary function half-session component is active 
for the origin-destination pair in a node providing the boundary function. <A session 
activation request is needed. 

Bytes 2 and 3 may contain the following sense code specific information: 


0000 No specific code applies. 


0001 The receiver received a request other than session control request when no LU-LU 
session was active. 


0002 The receiver received a request other than session control request when no 
LU-SSCP session was active. 


0003 The receiver received a session control request other than BIND/UNBIND when no 
LU-LU session was active. 


0004 The receiver received an UNBIND when no LU-LU session was active. 


0005 The receiver received a session control request other than ACTLU/DACTLU for the 
LU-SSCP session when no LU-SSCP session was active. 


0006 The receiver received DACTLU when no LU-SSCP session was active. 
8006 Invalid FID: Invalid FID for the receiving node. (Note 1) 
8007 Segmenting Error: First BIU segment had less than 10 bytes; or mapping field sequenc- 


ing error, such as’ first, last, middle; or segmenting not supported and MPF not set to 
ll. (Note 2) 
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8008 


8009 


800A 


800B 
800C 


800D 


800E 


800F 


8010 


8011 


8012 


8013 


PU Not Active: The SSCP-PU secondary half-session in the receiving node has not been 
activated and the request was not ACTPU for this half-session; for example, the 
request was ACTLU from an SSCP that does not have an active SSCP-PU session with the 
PU associated with the addressed LU. 


LU Not Active: The destination address specifies an LU for which the SSCP-LU second- 
ary half-session has not been activated and the request was not ACTLU. 


Too-Long PIU: Transmission was truncated by a receiving node because the PIU exceeded 
a maximum length or sufficient buffering was not available. 


Incomplete TH: Transmission received was shorter than a TH. (Note 1) 
DCF Error: Data Count field inconsistent with transmission length. 


Lost Contact: Contact with the link station for which the transmission was intended 
has been lost, but the link has not failed. If the difference between link failure 
and loss of contact is not detectable, link failure (X'8002') 1s sent. . 


Unrecognized Origin: The origin address specified in the TH was not recognized. 


Invalid Address Combination: The (DAF',OAF') (FID2) combination or the LSID (FID3) 
specified an invalid type of session, e.g.» a PU-LU combination. 


Segmented RU Length Error: An RU was found to exceed a maximum length, or required 
buffer allocation that might cause future buffer depletion. 


ER Inoperative or Undefined: A PIU was received from a subarea node that does not 
support ER and VR protocols, and the explicit route to the destination is inoperative | 
or undefined. | 


Subarea PU Not Active or Invalid Virtual Route: <A session-activation request for a 
peripheral PU or LU cannot be satisfied because there is no active SSCP-PU session for 
the subarea node providing boundary function support, or the virtual route for the 
specified SSCP-PU_T1I2 or SSCP-LU session is not the same as that used for the SSCP-PU 
session of the PU_T1|2's or LU's subarea PU. 


COS Not Available: A session activation request cannot be satisfied because none of 
the virtual routes requested for the session is available. 


Bytes 2 and 3 following the sense code contain sense code specific information. Set- 
tings allowed are: | 


Byte 2 indicates the environment in which the failure was detected: 
00 Single network 


01 Interconnected network: Failure was detected at a node in a subnetwork other 
than that of the NAU sending the activation request. 


Byte 3 indicates the reason for the session-activation failure: 


00 No Specific Code Applies: This means an error occured, but none of the condi- 
tions listed below applies. 


01 No Mapping Specified: A session-activation request cannot be satisfied because 
for each VR in the VR identifier list for the session, no VR to ER mapping is 
specified. 


02 No Explicit Routes Defined: A session-activation request cannot be satisfied 
because each VR in the VR identifier list for the session maps to a correspond- 
ing ER that is not defined. 


03 No VR Resource Available: <A session-activation request cannot be satisfied 
because each VR specified in the VR identifier list for the session requires a 
node resource that is not available. 


04 No Explicit Routes Operative: <A session-activation request cannot be satisfied 
because no underlying ER is operative for any VR specified in the VR identifier 
list for the session. 


05 No Explicit Route Can Be Activated: A session-activation request cannot be sat- 
isfied because no VR specified in the VR identifier list for the session mapped 
to a defined and operative ER that could be activated. 
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8017 


Notes: 


06 No Virtual Route Can Be Activated: A session-activation request cannot be sat- 
isfied because no VR specified in the VR identifier list for the session can be 
activated by the PU, though for at least one VR an underlying ER is defined, 
operative, and activated. ! 


07 No Virtual Route Identifier List Available:- A session-activation request cannot 
be satisfied because a VR identifier list is not available. 


Note: If none of the virtual routes specified in the VR identifier list for the ses- 
sion is active or can be activated, the reported reason is set based on a hierarchy of 
failure events. The "highest" of the failures that occurred within the set of virtual 
routes 1s returned on the response. For example, if the VR manager receives a nega~ 
tive response to an NC_ACTVR request for a VR specified in the VR identifier list and 
for all other VRs in the list no VR to ER mapping is specified, then reason X'06' is 
reported. The hierarchy of the failure reasons is in ascending numeric order, that 
iS,» reason X'02' is higher than reason X'Ol'. 


PIU from Adjacent Pre-ER-VR Subarea Node Rejected: A PIU that requires intermediate 
path-control routing was received by a subarea node from an adjacent subarea node that 
does not support ER-VR protocols, but the receiving subarea node does not support 
intermediate path-control routing for adjacent subarea nodes that do not support ER-VR 
protocols. 


1. It is generally not possible to send a response for this exception condition, since informa- 
tion (FID, addresses) required \.> generate a response is not available. It is logged as an 
error if this capability exists in the receiver. 


2. If segmenting is not supported, a negative response is returned for the first segment only, 
since this contains the RH. Subsequent segments are discarded. 
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APPENDIX N. NOTATION 


Seed 


Figure N-1 illustrates the notation used in the flow diagrams in this book. 


SNA-defined message units, such as the CDINIT RU, are capitalized. Representations of classes 
of RUs are in mixed case. The symbol "|" is used to mean "exclusive or." For example, 
"INIT-SELFIINIT-OTHER" means either INIT-SELF or INIT-OTHER. The symbol '*'' is used to denote 
"any value." For example, ''TERM*¥' means any RU whose acronym starts with "TERM. 


Flows are shown by arrows, with "®"' symbols in the columns of the components that send or 
receive the message unit. For example, component C sends RU 1 to component A; component B does 
not process the RU. Component C sends RU 2 to component B, which processes it and forwards it 
to component A. 


A component must do something with the message unit besides the cross-network address transfor- 
mation in order to have a "'@" symbol in its column. Thus, even though an RU flowing between two 
gateway SSCPs is transferred between two networks by the gateway node, no "®¢'' symbol appears in 
the gateway node column unless it does some processing related to the RU, such as requesting a 
virtual route in the second network in response to an ACTCDRM RU. 

The numbers on the left correspond to explanations in the text. 


Many RUs carry a list of optional control vectors. A list of control vectors is denoted "CV 
X'HH', X'HR',...," where ## is the hexadecimal number of a control vector. 


The purpose of a NOTIFY RU is indicated by a NOTIFY vector. NOTIFY vectors are shown as the 
first parameter of a NOTIFY RU: "NOTIFY(X'##')," where ## denotes a hexadecimal number. 


Negative responses carry sense data indicating the reason for the rejection of the request. 


Sense data is denoted "SD X'#HHHHHHH'," where ##% denotes a hexadecimal number. The final two 
bytes are generally omitted when they are X'0000'. 


Reed 


RU 1 
RSPCRU 1) 


RU 2 


Figure N-1. Flow Notation Examples 
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APPENDIX T. JERMINOLOGY: 


ACTCDRM 
ACTPU 


ASCII 


BIND 


BINDF 


CDCINIT 
CDINIT 
CDRM 
CDSESSEND 
CDSESSSF 
CDSESSST 
CDSESSTF 
CDTERM 
CINIT 
CLEANUP 
CONTACTED 
cos 
CTERM 


CV 


TCDRM 


DACTPU 


ACRONYMS AND ABBREVIATIONS 


ACTIVATE CROSS-DOMAIN RESOURCE MANAGER 
ACTIVATE PHYSICAL UNIT 


American Standard Code for Information Interchange 


BIND SESSION 


BIND FAILURE 


CROSS-DOMAIN CONTROL INITIATE 
CROSS-DOMAIN INITIATE 

Cross-Domain Resource Manager 
CROSS-DOMAIN SESSION ENDED 
CROSS-DOMAIN SESSION SETUP FAILURE 
CROSS-DOMAIN SESSION STARTED 
CROSS-DOMAIN SESSION TAKEDOWN FAILURE 
CROSS-DOMAIN TERMINATE 

CONTROL INITIATE 

CLEAN UP SESSION 

CONTACTED 

class of service 

CONTROL TERMINATE 


control vector 


DEACTIVATE CROSS-DOMAIN RESOURCE MANAGER 


DEACTIVATE PHYSICAL UNIT 
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DLU destination LU 


DQ dequeue 

DSRLST DIRECT SEARCH LIST 

ENA Extended Network Addressing 

ER explicit route 

ER_TESTED EXPLICIT ROUTE TESTED 

Exp expedi ted 

EXR EXCEPTION REQUEST 

FM function management 

FMD function management data 

FMD NS(c) function management data, network services, configuration services 
FMD NS(ma) function management data, network services, maintenance services 
FMD NS(s) function management data, network services, session services 
FMH FM header 

FMP. FM profile 

I initiate 

ID identifier, identification 

ILU initiating LU (LU sending INIT-SELF) 

INIT initiate 

INIT-OTHER INITIATE-OTHER 

INIT-OTHER-CD INITIATE-OTHER CROSS DOMAIN 

INIT-SELF INITIATE-SELF 
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IPL 


LNS 


LU 


MU 


NAU 


NC 


NC-ER-TEST-REPLY 


Norm 


NS 


OLU 


PC 


PCID 


PLU 


REQACTCDRM 


RH 


RNAA 


Initial Program Load 


logical unit network services 


logical unit 


message unit 


network addressable unit 
network control 

EXPLICIT ROUTE TEST REPLY 
normal 


network services 


origin LU 


path control 

procedure correlation identifier 

primary LU 

physical unit 

physical unit in a type 4 or type 5 node 


physical unit control point 


queue, queued 


REQUEST ACTIVATION OF CROSS-NETWORK RESOURCE MANAGER 
request/response header 


REQUEST NETWORK ADDRESS ASSIGNMENT 
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ROUTE-INOP 
ROUTE-TEST 
RQ 

RSP 


RU 


SA 

sc 

sc 

SD 
SESSEND 
SESSST 
SETCV 
SLU 
SNA 
SNT 
SON 


SSCP 


TERM 
TERM-OTHER 
TERM-SELF 
TH 


TLU 


ROUTE INOPERATIVE 
ROUTE TEST 
request 

response 


request/response unit 


search argument 

session control 

session connector 

sense data 

SESSION ENDED 

SESSION STARTED 

SET CONTROL VECTOR 
secondary LU 

Systems Network Architecture 
SNA Network Interconnection 
session outage notification 


system services control point 


terminate, terminating, termination, terminal 
TERMINATE-OTHER 

TERMINATE-SELF 

transmission header 


terminating logical unit (LU sending TERM) 
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UNBIND UNBIND SESSION 


UNBINDF UNBIND FAILURE 
URC user request correlation 
VR virtual route 
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SPECIAL CHARACTERS 


| (vertical stroke), to mean "exclusive 

or" N-1 

* (asterisk), to mean "any value" or "don't 
care" N-1] ; 


gS 


accounting data collection 1-32 
ACTCDRM E-4 
See also ACTIVATE CROSS-DOMAIN RESOURCE 
MANAGER 
ACTCDRM contention 1-32 
ACTIVATE CROSS-DOMAIN RESOURCE MANAGLR? 
(ACTCDRM) 1-12, 1-13, 1-34, 1-36, E-4 
ACTIVATE PHYSICAL UNIT (ACTPU) I-12, 1-13; 
E-5 
Activation Request/Response Sequence Identi- 
fier Control Vector 1-34, 1-36, E-50 
ACTPU E-5 . . 
See also ACTIVATE PHYSICAL UNIT 
address 
alias 1-16, 1-17, 1-18, 1-22, 1-23, 1-32, 
1-35, 1-36, 1-37 
dynamically assigned 1-16, 1-18 
network-ID-qualified 1-2, 1-16, 1-18 
real 1-17, 1-18, 1-22, 1-23, 1-27, 1-37 
system-defined 1-16, 1-18 
for gateway SSCP 1-17, 1-18 
address aliasing 1-1, 1-16, 1-33 
address assignment 1-32, 1-37 
algorithm 1-16 
protocols 1-17 
address space 
peripheral 1-13 
subarea 1-1, 1-2, 1-12, 1-13, 1-16 
address transform 1-12, 1-18, 1-31, 1-32, 
1-34, 1-36, 1-38 
address transformation 
by a gateway node 1-17, 1-18, 1-32 
by a gateway SSCP 1-10, 1-18, 1-22, 1-23 
addresses in intermediate subnetworks 1-18 
adjacent SSCP, definition 1-25 
adjacent-SSCP list 1-25, 1-26 
alias address 1-16, 1-17, 1-18, 1-22, 1-23, 
1-35, 1-36 
assignment 1-32, 1-37 
alias LU name 1-19, 1-20, 1-22, 1-23, 1-27, 
1-31 
aliasing 
address I-1, 1-16, 1-33 
name I-1, 1-6, 1-19, 1-20 


BIND E-5 
See also BIND SESSION 
BIND FAILURE (BINDF) 1-29, E-11 
BIND image 1-39 
BIND SESSION (BIND) 1-2, I-11, 1-22, 1-29, 
1-39, E-5 
name transformation 1-21, 1-32 
BINDF E-11 
See also BIND FAILURE 
boundary function 1-28, 1-39 
compared to gateway function 1-13 
boundary function to gateway function 
flow 1-15 


gi 


category value, sense code 6-1 
See also sense data 
CDOCINIT E-1ll 
See also CROSS-DOMAIN CONTROL INITIATE 
CBINIT E-11 
See also CROSS-DOMAIN INITIATE 
CDRM Control Vector 1-26, 1-34, 1-36, E-49 
CDOSESSEND E-14 
See also CROSS-DOMAIN SESSION ENDED 
CDOSESSSF E-14 
See also CROSS-DOMAIN SESSION SETUP FAIL- 
URE 
CDSESSST E-15 
See also CROSS-DOMAIN SESSION STARTED 
CDSESSTF E-15 
See also CROSS-DOMAIN SESSION TAKEDOWN 
FAILURE 
CDTERM E-15 
See also CROSS-DOMAIN TERMINATE 
CINIT E-16 
See also CONTROL INITIATE 
class of service (COS) name 1-2, 1-19, 1-21, 
1-22, 1-27, 1-31, 1-33, 1-37 
definition 1-21 
CLEAN UP SESSION (CLEANUP) 1-40, E-18 
CLEANUP E-18 
See also CLEAN UP SESSION 
Clear Data Structured Data Subfield E-42 
composite SSCP I-11 
configurations of interconnected subnetworks 
parallel gateways 1-3 
gateway components 1-7 
gateway node selection I-11, 1-26, 
1-27 
single gateway, three or more subnet- 
works 1-3 
gateway components 1-8 
single gateway, two subnetworks 1-3 
gateway components 1-5, 1-6 
tandem gateways 1-3, 1-4 
gateway components 1-9, 1-10 
LU name aliasing 1-20 
SSCP rerouting 1-23 
SSCP-SSCP session activation 1-36 


Index X-1 


CONTACTED 1-12, E-18 
CONTROL INITIATE (CINIT) I-11, 1-39, E-16 
Control List 
LU Status E-57 
Other-Network SSCP E-57 
CONTROL TERMINATE (CTERM) 1-41, E-19 
Control Vector 
Activation Request/Response Sequence Iden- 
tifier 1-34, 1-36, E-50 
CDRM 1-26, 1-34, 1-36; E-49 
Control Vector Keys Not Recognized E~-56 
ER Configuration 1-12, E-55 
Gateway Support Capabilities 1-34, 1-36, 
E-52 
IPL Load Module Request E-55 
Local Form Session Identifier E-55 
Mode/COS/VRID List E-51 
Names Substitution 1-37, 1-38, E-53 
NAU Address 1-27, 1-34, 1-36, 1-37, 1-38, 
E-54¢ 
Network Name E-51 
Network-Qualified Address Pair 1-34, 
1-36, 1-37, 1-38, 1-39, 1-41, E-53 
PU FMD-RU-Usage E-50 
Resource Identifier 1-25, 1-26, 1-27; 
1-37, 1-38, E-54¢ 
Session Initiation 1-26, 1-27, 1-37, 
1-38, E-52 
SSCP Identifier 1-25, 1-27, E-53 
SSCP Name 1-34, 1-36, E-54 
SSCP-PU Session Capabilities 1-12, 1-13, 
E-51 
VR-ER Mapping Data 1-39, E-54 
VRID List 1-22, 1-34, 1-36, 1-37, 1-38, 
E-54 
Control Vector Keys Not Recognized Control 
Vector E-56 
COS name 1-19, l-21, 1-22, 1-27, 1-31, 1-33 
CROSS-DOMAIN CONTROL INITIATE 
(CDCINIT) 1-11, 1-24, 1-39, E-11 
CROSS-DOMAIN INITIATE (CDINIT) 1-2, 1I-ll, 
1-20, 1-21, 1-23, 1-24, 1-25, 1-26, 1-27, 
1-29, 1-31, 1-37, E-11 
queuing 1-38 
CROSS-DOMAIN SESSION ENDED (CDSESSEND) 1-24, 
1-30, 1-41, E-14 
CROSS-DOMAIN SESSION SETUP FAILURE 
(CDSESSSF) 1-24, 1-29, E-14 
CROSS-DOMAIN SESSION STARTED 
(CDSESSST) I-11, 1-24, 1-29, 1-39, E-15 
CROSS-DOMAIN SESSION TAKEDOWN FAILURE 
(CDSESSTF) 1-24, 1-29, E-15 
CROSS-DOMAIN TERMINATE (COTERM) 1-2, 1-24, 
1-29, 1-30, 1-40, 1-41, E-15 
Cross-Gateway Resource Available NOTIFY Vec- 
tor 1-24, 1-25, 1-27, 1-31, E-32 
Cross-Gateway Resource Requested NOTIFY Vec- 
tor 1-24, 1-27, 1-31, E-31 
cross-network directory 1-26 
cross-network session 1-1, 1-2, 1-5, 1-12, 
1-17 
SSCP-SSCP 1-23 
CTERM E-19 
See also CONTROL TERMINATE 


DACTCDRM E-19 
See also DEACTIVATE CROSS-DOMAIN RESOURCE 
MANAGER 
DACTPU E-20 
See also DEACTIVATE PHYSICAL UNIT 
DEACTIVATE CROSS-DOMAIN RESOURCE MANAGER 
(DACTCDRM) 1-30, 1-40, E-19 
DEACTIVATE PHYSICAL UNIT (DACTPU) 1-12, 
1-13, 1-32, E-20 
destination LU (DLU) I-11, 1-12, 1-17, 1-20, 
I-21, 1-22, 1-23, 1-25, 1-26, 1-27, 1-30, 
1-31, 1-37, 1-38 
definition 1-2 
DIRECT SEARCH LIST (DSRLST) E-20 
Search argument X'02' 1-24, 1-27, 1-31 
Search argument X'03' 1-27 
DLU 1-2, I-11, 1-12, 1-17, 1-20, 1-21, 1-22, 
1-23, 1-25, 1-26, 1-27, 1-30, I-31, 1-37, 
1-38 
DSRLST E-20 
See also DIRECT SEARCH LIST 
dynamically assigned address 1-16, 1-18 


a 


Enciphered Data Structured Data Sub- 
field E-42 
ER Configuration Control Vector 1-12, E-55 
ER-TESTED E-2l 
See also EXPLICIT ROUTE TESTED 
error category 
See sense data 
EXPLICIT ROUTE TEST REPLY 
(NC-ER-TEST-REPLY) 1-12, E-28 
EXPLICIT ROUTE TESTED (ER-TESTED) I-12, 
1-13, E-21 
EXR (EXCEPTION REQUEST } 
sense data included with 6-1 


[| 


Fully Qualified PLU Network Name Structured 
Data Subfield E-41 
Fully Qualified SLU Network Name Structured 
Data Subfield E-42 


Le 


gateway function 1-1, 1-2, 1-12, 1-13 
functions 1-31 
structure 1-16 
gateway function to boundary function 
flow 1-15 
gateway node 1-1, 1-2, 1-12, 1-15, 1-16, 
1-17 
gateway node selection 1-11, 1-26, 1-27 
gateway node support 1-8, 1-9, 1-10, 1-11 
definition 1-2 
gateway PU 1-1, 1-17 
functions 1-31, 1-32 
shared control of 1-2 
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gateway SSCP 1-1, 1-2, 1-5, 1-6, 1-7, 1-8, 
1-9, 1-10, 1-11, 1-17, 1-19 
functions 1-30 
Gateway Support Capabilities Control Vec- 
tor 1-34, 1-36, E-52 
gateway-capable components 1-1, 1-10 
gateway, definition 1-2 


[| 


ILU 1-2, 1-37 
ILU/TLU or Third-party SSCP Notification 
NOTIFY Vector E-31 
INIT-OTHER E-22 
See also INITIATE-OTHER 
INIT-OTHER-CD E-24 
See also INITIATE-OTHER CROSS-DOMAIN 
INIT-SELF E-26 
See also INITIATE-SELF 
INIT-SELF Format 0 
See INITIATE-SELF 
INIT-SELF Format 1 and 2 
See INITIATE-SELF 
INITIATE-OTHER CINIT-OTHER) 1-2, 1-37, 1-38, 
E-22 
INITIATE-OTHER CROSS-DOMAIN 
(INIT-OTHER-CD) E-24 
INITIATE-SELF (INIT-SELF) 1-2, 1-11, 1-37; 
1-38, E-26 
initiating LU (ILU) 1-37 
definition 1-2 
IPL Load Module Request Control Vector E-55 


a 


Local Form Session Identifier Control Vec- 
tor E-55 
loop in rerouting path 1-25 
LU name 1-21, 1-26 
alias 1-19, 1-20, 1-22, 1-23, 1-27, 1-31 
network-ID-qualified 1-2, 1-17, 1-20, 
1-23, 1-27, 1-31 
real 1-17, 1-19, 1-20, 1-22, 1-23, 1-27, 
1-31 
LU name transform 1-37, 1-38 
LU network services (LNS) 1-16 
LU Status Control List E-57 
LU-LU session awareness 
maintained by a gateway node 1-28, 1-29, 
1-30, 1-32 
maintained by a gateway SSCP 1-23, 1-28, 
1-29, 1-30, 1-31, 1-39, 1-41 
LU-LU Session Services Capabilities NOTIFY 
Vector E-32 


ci 


mode name 1-2, 1-19, 1-27, 1-31 
definition 1-21 
Mode Name Structured Data Subfield E-41 
Mode/COS/VRID List Control Vector E-51 
modifier value, sense code G-1 
See also sense data 


a 


name 
COS 1-19, 1-21, 1-22, 1-23, 1-27, 1-31; 
1-33 
gateway node 1-27 
LU 1-21, 1-26 
alias 1-19, 1-20, 1-22, 1-23, 1-27; 
1-31 
network-ID-qualified 1-2, 1-17, 1-20, 
1-23, 1-27, 1-31 
real 1-17, 1-19, 1-20, 1-22, 1-23, 
1-27, 1-31 
mode 1-2, 1-19, 1-21, 1-22, 1-23, 1-27; 
1-31 
SSCP 1-2, 1-19, 1-26, 1-35 
name aliasing 1-1, 1-6, 1-19, 1-20 
name space l-l, 1-2, 1-19, 1-21 
name transform 1-12, 1-21, 1-31, 1-32, 1-37; 
1-38 
name transformation 1-2, 1-10 
by a gateway node 1-21, 1-32 
by a gateway SSCP 1-19, 1-20, 1-22, 1-23 
Names Substitution Control Vector 1-37, 
1-38, E-53 
native network 1-12, 1-15 
definition 1-12 
NAU Address Control Vector 1-27, 1-34, 1-36; 
1-37, 1-38, E-54 
NC-ER-TEST-REPLY E-28 
See also EXPLICIT ROUTE TEST REPLY 
negative response 
sense data included with 6-1 
Network Address Pair Session Key €E-58 
network identifier 1-2, 1-12, 1-16, 1-26 
Network Name Control Vector E-51 
Network Name Pair or Uninterpreted Name Pair 
Session Key E-58 
Network or Uninterpreted Name Session 
Key E-58 | 
network-ID-qualified address 1-2, 1-16, 1-18 
network-ID-qualified LU name 1-2, 1-17, 
1-20, 1-23, 1-27, 1-31 
Network-Qualified Address Pair Control Vec- 
tor 1-34, 1-36, 1-37, 1-38, 1-39, 1-41, 
E-53 
Network-Qualified Address Pair Session 
Key E-58 
NOTIFY E-29, E-30 
NOTIFY Vector 
Cross-Gateway Resource Available 1-24, 
1-25, 1-27, 1-31, E-32 
Cross-Gateway Resource Requested 1-24, 
1-27, 1-31, E-31 
ILU/TLU or Third-party SSCP Notifica- 
tion E-31 
LU-LU Session Services Capabilities E-32 
Resource Available E-31 
Resource Requested E-30 
NOTIFY(X'05') 1-12, 1-13, 1-18, 1-29, 1-30, 
1-32, 1-39, 1-41 
NOTIFY(X'06') 1-24, 1-27, 1-31 
NOTIFY(X'08') 1-24, 1-25, 1-27, 1-31 


Index X-3 


OLU 1-2, 1-11, 1-17, 1-20, 1-21, 1-22, 1-23, 


1-26, 1-27, 1-30, 1-31, 1-37, 1-38 
origin LU (OLU) 1-11, 1-17, 1-20, 1-21, 
1-22, 1-23, 1-26, 1-27, 1-30, 1-31, 1-37, 
1-38 
definition 1-2 
Other-Network SSCP Control List E-57 


i 


parallel gateways 1-3 
gateway components 1-7 
gateway node selection 1-11, 1-26, 1-27 
path assignment 1-22, 1-32 
path control, subarea 1-12 
path-determining RUs 1-24, 1-25, 1-27 
path, session setup 1-11, 1-20, 1-21, 1-23, 
1-24, 1-25, 1-26, 1-27, 1-28, 1-30, 1-31; 
1-37, 1-38, 1-39, 1-40 


PCID (procedure correlation identifier) 1-25 


transformation 1-27, 1-31, 1-33 
PCID Session Key E-58 
pending-active session 1-12, 1-31, 1-32, 
1-40 
pending-reset session 1-12, 1-31 
peripheral path control 1-15 
PLU 1-2, 1-11, 1-28, 1-30, 1-39, 1-4] 
predesignated gateway SSCP 1-11 
functions 1-31 
primary LU (PLU) 1-11, 1-28, 1-30, 1-39, 
1-41 
definition 1-2 
procedure correlation identifier 
(PCID) 1-25, 1-27, 1-31, 1-33 
PU FMD-RU-Usage Control Vector E-50 


[2 


queued session request 1-38, 1-40 


Gg 


real address 1-17, 1-18, 1-22, 1-23, 1-27, 
1-37 
real LU name 1-17, 1-19, 1-20, 1-22, 1-23, 
1-27, 1-31 
receive check 
sense data included with 6-1 
REQACTCDRM E~-32 
See also REQUEST ACTIVATION OF 
CROSS-NETWORK RESOURCE MANAGER 
REQUEST ACTIVATION OF CROSS-NETWORK RESOURCE 
MANAGER (REQACTCDRM) I-12, 1-13, 1-32; 
1-35, 1-36, E-32 
REQUEST. NETWORK ADDRESS ASSIGNMENT 
(RNAA) 1-2, 1-12, 1-13, 1-17, 1-18) 1-20, 
1-26, 1-31, 1-32, 1-34, 1-35, 1-36, 1-37, 
1-38, E-33 
rerouting loop 1-25 
rerouting, SSCP 1-1, 1-2, 1-10, 1-11, 1-23, 
1-24, 1-25, 1-26, 1-27, 1-30, 1-33 


Resource Available NOTIFY Vector E-31 
Resource Identifier Control Vector 1-25, 
1-26, 1-27, 1-37, 1-38, E-54 
Resource Requested NOTIFY Vector E-30 
RNAA E-33 
See also REQUEST NETWORK ADDRESS ASSIGN- 
MENT 
ROUTE INOPERATIVE (ROUTE-INOP) 1-12, -1-13, 
E-34 
route outage I-12, 1-29, 1-30, 1-32, 1-40 
route status reporting 1-12, 1-30 
route testing 1-12, 1-30 
ROUTE-INOP E-34 
See also ROUTE INOPERATIVE 
ROUTE-TEST 1-12, 1-13, E-35 
RSPCACTCDRM) 1-34, 1-36, E-43 
RSPCACTPU) E-43 
RSP(BIND) 1-39, E-44 
RSP(CDINIT) IJl-11, 1-21, 1-22, 1-27, 1-37; 
1-38, E-45 
RSP(CDTERM) E-46 
RSP(CINIT) 1-39, E-46 
RSP(DSRLST) E-46 
RSPCINIT-OTHER-CD) E-46 
RSP(RNAA) 1-34, 1-36, 1-37, 1-38, E-47 
RSP(ROUTE-TEST) E-47 


[S| 


secondary LU (SLU) I-11, 1-22, 1-28, 1-30, 
1-39, 1-41 

definition 1-2 
send check 

sense data included with G-1 
sense code 

See sense data 
sense data G-1 

format of G-1 

sense code 

category X'00' (user sense data 


only) G-1l 
category X'08' (request reject) G-I, 
G-1 
category X'10° (request error) 6-14, 
G-1 


category X'20' (state error) G-16, G-1l 
category X'S40' (RH usage error) G-17; 
G-l 
category X'80' (path error) 6-19, G-1l 
modifier G-1 
modifier value of X'00' G-I1 
sense-code specific information G-1 
user-defined data G-1 
sense-code specific information G-I1 
SESSEND E-35 
See also SESSION ENDED 
session activation 1-16 
cross-network LU-LU session 1-12, 1-39 
cross-network SSCP-SSCP session 1-30, 
1-34, 1-35, 1-36 
session awareness 1-23, 1-28, 1-29, 1-30; 
1-31, 1-39, 1-41 
session connector 1-13, 1-16 
connection to path control 1-32 
creation 1-32 
destruction 1-32 
functions 1-32 
session contention, SSCP-SSCP 1-32 
session deactivation 1-16 
cross-network LU-LU session 1-12, 1-41 
cross-network SSCP-SSCP session 1-40 
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SESSION ENDED (SESSEND) 1-30, 1-41, E-35 
session initiation 1-2, 1-5, 1-8, 1-11, 
1-16, 1-17, 1-28, 1-37, 1-38 
Session Initiation Control Vector 1-26, 
1-27, 1-37, 1-38, E-52 
Session Instance Identifier Structured Data 
Subfield E-41 
Session Key 
Network Address Pair E-58 
Network Name Pair or Uninterpreted Name 
Pair E-58 
Network or Uninterpreted Name E-58 
Network-Qualified Address Pair E-58 
PCID E-58 
URC E-58 
Session Keys 
table of E-58 
Session manager, gateway function 1-16 
functions 1-31 
session outage notification (SON) 1-12, 1-32 
session override, SSCP-SSCP 1-32 
session parameters 1-21, 1-39 
Session Qualifier Structured Data Sub- 
field E-41 
session services RUs 1-10, I-11, 1-17, 1-18, 
1-20, 1-23, 1-24, 1-26 
session setup error I-12 
session setup path 1-11, 1-20, 1-21, 1-24, 
1-25, 1-26, 1-27, 1-28, 1-30, 1-31, 1-37, 
1-38, 1-39, 1-40 
definition 1-23 
SESSION STARTED (SESSST) I-11, 1-39, E-36 
session termination 1-2, 1-11, 1-18, 1-30, 
1-41 
SESSST E-36 
See also SESSION STARTED 
SET CONTROL VECTOR (SETCV) 1-2, 1-12, 1-13; 
1-17, 1-18, 1-21, 1-22, 1-31, 1-32, 1-34, 
1-35, 1-36, 1-37, 1-38, E-36 
SETCV E-36 
See also SET CONTROL VECTOR 
single gateway, three or more subnet- 
works 1-3 
gateway components 1-8 
SLU 1-2, 1-11, 1-22, 1-28, 1-30, 1-39, 1-41 
SSCP Identifier Control Vector 1-25, 1-27, 
E-53 
SSCP name 1-2, 1-19, 1-26, 1-35 
SSCP Name Control Vector 1-34, 1-36, E-54 
SSCP notification 
when session ended 1-32, 1-41 
when session started 1-32, 1-39 
SSCP rerouting l1-1, 1-2, 1-10, 1-11], 1-24; 
1-25, 1-26, 1-27, 1-30, 1-33 
definition 1-23 
SSCP-PU Session Capabilities Control Vec- 
tor 1-12, 1-13, E-51 
SSCP-SSCP session override 1-32 
SSCP-SSCP session, cross-network 1-23 
Structured Data Subfield 
Clear Data E-42 
Enciphered Data E-42 
Fully Qualified PLU Network Name E-41 
Fully Qualified SLU Network Name E-42 
Mode Name E-41 
Session Instance Identifier E-41 
Session Qualifier E-41 
Unformatted Data E-41 
subarea address space I-1l, 1-2, 1-13, 1-16 
subarea path control 1-12, 1-13, 1-15, 1-16 
subarea/element split 1-1, 1-16 
Symbol string 
Type A E-1l 


Type AE E-1 
Type G E-I1 
Type GR E-1 
Type USS E-1 
system-defined address 1-16, 1-17, 1-18 


tandem gateways 1-4 
gateway components 1-9, 1-10 
LU name aliasing 1-20 
SSCP rerouting 1-23 
SSCP-SSCP session activation 1-36 
TERM-OTHER E-37 
See also TERMINATE-OTHER 
TERM-SELF E-38 
See also TERMINATE-SELF 
TERM-SELF Format 0 
See TERMINATE-SELF 
TERM-SELF Format 1 
See TERMINATE-SELF 
TERMINATE-OTHER (TERM-OTHER) 1-2, 1-41, E-37 
TERMINATE-SELF (TERM-SELF) 1-2, 1-41, E-38 
transformation 
address 1-10, 1-17, 1-18, 1-22, 1-23, 
1-32 
COS name 1-19, 1-21, 1-23, 1-31, 1-33 
LU name 1-19, 1-20, 1-21, 1-22, 1-23, 
1-31, 1-32, 1-33 
mode name 1-19, 1-21, 1-23, 1-31, 1-33 
name 1-2, 1-10 
PCID 1-27, 1-31, 1-33 
transmission header (TH) 1-17, 1-18, 1-32, 
1-33 
trial and error SSCP rerouting 1-25 
Type A symbol string E-1 
Type AE symbol string E-I 
Type G symbol string E-1 
Type GR symbol string E-1 
Type USS symbol string E-1 


fy 


UNBIND E-39 
See also UNBIND SESSION 
UNBIND FAILURE (UNBINDF) 1-29, E-40 
UNBIND SESSION (UNBIND) 1-29, 1-41, E-39 
UNBINDF E-40 
See also UNBIND FAILURE 
Unformatted Data Structured Data Sub- 
field E-41 
Uninterpreted Name Pair or Network Name Pair 
Session Key E-58 
URC Session Key E-58 


virtual route 1-2, 1-21, 1-22, 1-33, 1-36 
activation 1-32 
VR identifier list 1-12, 1-21, 1-22, 1-31, 
1-32, 1-33, 1-34, 1-36, 1-38 
VR-ER Mapping Data Control Vector 1-39, E-54 
VRID List Control Vector 1-22, 1-34, 1-36, 
1-37, 1-38, E-54 
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